NAPI в сетевых драйверах Linux

[@amarao]

Что-то слишком просто. А где тут всякие gso/lro/ntuple?

[@LordDominator]

amarao, ethtools не поместился, хотелось рассказать максимально кратко. Буду дальше над этой темой работать

[@amarao]

Где-то я слышал, что из-за всяких хуков на хардварный оффлоадинг, код получился настолько медленным, что тестовый сетевой драйвер без hw offload оказался такой же быстрый, но много проще.

[@acmnu]

Есть ли вообще смысл использовать ядро, если мы говорим о высокой производительности? Или надо уходить в bypass. Вот например хороший текст об этом от cloudflare https://blog.cloudflare.com/kernel-bypass/

[@LordDominator]

acmnu, спасибо, про bypass не слышал, прочитаю

[@BigPack]

Байпас мнее безопасный, хотя есть решения и в эту сторону: www.usenix.org/system/files/conference/osdi14/osdi14-paper-belay.pdf.

Еще с байпасом надо писать/адаптировать/поддерживать свой стек (это, конечно, не RDMA, но все равно дополнительная работа).

Но байпас хорош, когда надо сильно оптимизировать стек, и иногда выше, чем транспорт. Замечательная статья: www.usenix.org/conference/nsdi19/presentation/kalia на тему запуска RPC стека в байпасе, средняя раунд-трип 2.3 us (по сути, пракический потолок по PCIe и ToR сети)! Но опять же, очень очень много вопросов по безопасности. Этот результат они получили через raw драйвер, т.е. даже байпася DPDK, напярмую кидая пакеты на NIC ;)

[@acmnu]

Еще с байпасом надо писать/адаптировать/поддерживать свой стек 

Так есть же уже вроде готовые библиотеки, в которых все это сделано. Понятно, что они заточены под конкретные карточки, но они есть.

[@BigPack]

Ага, есть, очень много — в этом и проблема) Кстати, они могут работать на в принципе, любой карточке которая поддерживает их базовый фреймворк (e.g. DPDK, snabb). Тут все зависит от того, что мы хотим поднять на нем. В случае TCP — все не просто. TCP очень сложный и «mature» и его реализация в Linux Kernel шибко нетривиальная и весьма хорошо отлажена со временем. Готовые байпас TCP стеки обычно реализуют определенное подмножество TCP, и не на столько хорошо отлажены [ medium.com/@penberg/on-kernel-bypass-networking-and-programmable-packet-processing-799609b06898 ]. Плюс люди обычно спускаются до байпаса, когда хотят получить высокую (и стабильную) производительность при высокой нагрузке. В таких случаях, не всегда удается этого достичь только с байпасом, нужно и стек подкрутить. В общем, на практике, с байпасом больше возни получается. Фактичски, тут нет стандарта [ medium.com/@penberg/on-kernel-bypass-networking-and-programmable-packet-processing-799609b06898 ], есть много разных реализаций со своими упрощениям и багами, и все это не шибко хорошо поддерживается.

[@BigPack]

Метод poll может использоваться также и для передачи пакетов.

А как именно работает poll на передачу? На передаче, нужно кидать данные в кольцо, doorbell'ить NIC и тогда он сделает DMA и заберет данные с кольца. Если можно, было бы интересно узнать больше как тут работает пулинг, есть ссылочки, плиз?

[@BigPack]

Все, понял! Пулинг Completion Queue, видимо, имеется ввиду в статье. Тема неплохо раскрыта тут: arxiv.org/pdf/2002.02563.pdf. Извеняюсь за лишнее беспокойство.