Британская вещательная корпорация (BBC) открыла (https://www.bbc.co.uk/rd/blog/2018-04-high-speed-networking-...) код, разработанный в рамках проекта IP Studio для повышения пропускной способности систем потокового вещания через IP-сети. Разработка базируется на фреймворке Netmap и ориентирована на повышение пропускной способности в конфигурациях с 100-гигабитными каналами связи за счёт применения техники обхода штатных обработчиков пакетов сетевого стека ядра ('kernel bypass') и предоставления средств для прямой маршрутизации пакетов между приложениями и сетевым оборудованием.
Экспериментируя с разработкой программного продукта для потокового вещания инженеры BBC обратили внимание, что узким местом при обработке очень большого числа сетевых пакетов являются операции копирования пакетов в различные области памяти, которые в процессе обработки через стандартную систему сокетов производятся несколько раз. Использование
Netmap помогло сократить число операций копирования за счёт прямой передачи сразу нескольких пакетов сетевой карте. В качестве сетевого адаптера в BCC использовался Mellanox ConnectX-4, для которого имеется открытый драйвер для ядра Linux, но отсутствует поддержка в Netmap.
Разработчики BBC на основе имеющегося драйвера подготовили код для поддержки Mellanox в Netmap и добились производительности на уровне 80 гигабит в секунду при однопоточном тестировании. В итоге для включения в основной состав проекта Netmap (https://github.com/luigirizzo/netmap) был предложен (https://github.com/luigirizzo/netmap/commit/3e8cb728eebbcb09...) новый драйвер mlx5 с поддержкой прямого взаимодействия c 10/25/40/50/100-гигабитными сетевыми адапетрами Mellanox ConnectX-4 и ConnectX-5.
URL: https://www.bbc.co.uk/rd/blog/2018-04-high-speed-networking-...
Новость: https://www.opennet.dev/opennews/art.shtml?num=48548
Наконец-то!
Если не секрет, вам это зачем? Что за сфера?
Потоковое вещание, не?
Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как один из примеров это фильтрация DDoS атак
> Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
> один из примеров это фильтрация DDoS атакречь то вроде не о фильтрации на таких скоростях ....
>> Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
>> один из примеров это фильтрация DDoS атак
> речь то вроде не о фильтрации на таких скоростях ....Ну про проброс вроде обсудили выше, тут добавил ещё вариант применения.
netmap шаг назад, зачем он нужен когда есть dpdk.
Они сделали так, но вас никто не сдерживает что-то лучшее подготовить и предложить сообществу!
Это уже давно сделано, dpdk прокачивает 94 GbE на dpdk 17.02, погугли
> погуглиДиванный теоретик, за себя отвечай. Покажи замеры.
Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.
> Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.Вы вышли из криосна? DPDK уже давно поддерживает не только intel. В netmap нет поддержки SMP, например, как и почти всего остального.
>>В netmap нет поддержки SMP,А зачем SMP он там вообще нужен? Если цель - минимизация посрелников? Разные коннекты по разным процессорам и так разбегутся.
>>>В netmap нет поддержки SMP,
> А зачем SMP он там вообще нужен? Если цель - минимизация посрелников?
> Разные коннекты по разным процессорам и так разбегутся.Если шатные методы разделения потока оказываются не приемлимы, а это частая ситуация, так как обычно аппаратно поддерживается делёжка только по IP адресу и/или порту, то делить приходится программными методами, а это значит что для netmap приходится писать набор велосипедов, тогда как в dpdk всё из коробки.
> сетевыми адапетрами Mellanox ConnectX-4 и ConnectX-5.Так оно как бы тоже.
не пользуй
> netmap шаг назад, зачем он нужен когда есть dpdk.Ну так потому BBC и открыли код, наверное. :)
...Или наступили на грабли, которые сами не в состоянии исправить...
Для чего они выпускают 100Гбит адаптеры, если даже хитросделанный кастомный драйвер под линукс не могет столько прокачать?
Потому что они работают на тех ОС, которые таки могут его прокачать.
> Потому что они работают на тех ОС, которые таки могут его прокачать.Netmap есть под windows ;-)
> Потому что они работают на тех ОС, которые таки могут его прокачать.То есть ни на каких? То есть 1 гигабит это маркетинговый ход? Я так и знал.
>Потому что они работают на тех ОС, которые таки могут его прокачать.Т.е. на сферическо-вакуумных.
>>Потому что они работают на тех ОС, которые таки могут его прокачать.
> Т.е. на сферическо-вакуумных.https://medium.com/netflix-techblog/serving-100-gbps-from-an...
Вы уж определитесь - то бзда рипнутая и никому не нужная, то она сферическо-вакуумная.
Там достигнута была скорость 90Gbps и для этого пришлось использовать огромную кучу костылей и подпорок. Хотя надо признать, что многие из них были связаны не с сетевым стеком.
Речь про 80 гбит на один поток в новости.
Из оригинала не очень понятно каким был предел передачи без netmap. Проблема то понятная, но интересно на сколько решение улучшило положение вещей.
> Из оригинала не очень понятно каким был предел передачи без netmap. Проблема
> то понятная, но интересно на сколько решение улучшило положение вещей.Из новости понятно только то, что они добавили поддержку ещё одного вендора и всё. Улучшило так: не работало никак, стало работать.
Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
> Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стекеОбычно около 1Mpps на 1 процессоре (+- конечно, процессоры разные) при 100% загрузки. На dpdk около 20-100Mpps, netmap обычно показывает схожую производительность.
А не пробовали offload включить и слегка тюнить афинити ?
Там как не крути, всё равно мы упираемся в копирование, единственное что может хоть как-то спасти ситуацию, на мой взгляд, это packetv4+zc, который уже есть в наработках.
https://youtu.be/sVdVVMOjtoI?t=316
https://people.netfilter.org/hawk/presentations/nfws2014/dp-...Даже сискол это дорого уже на 10GbE
>> Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
> Обычно около 1Mpps на 1 процессоре (+- конечно, процессоры разные) при 100%
> загрузки. На dpdk около 20-100Mpps, netmap обычно показывает схожую производительность.DPDK неплохая технология, но называть конкретные цифры - это чистой воды маркетинг.
Да, тупой L2 форвардинг из порта в порт может и будет 20-100 mpps, но как только добавляется какая-то "умная" обработка, производительность драматически падает, иногда в 10 раз. И это при том, что для DPDK нужна куча приседаний и утилизация ядер всегда "в полку".
switchdev мне кажется куда более перспективной технологией, чем попытка переложить на процессор то, что на нём не надо обрабатывать.
Задача netmap/DPDK довести пакеты до процессора и вывести их в сеть, говорить, что обработка может драмматически падать глупо, так как это не относится к функциям netmap/dpdk.В данном случае нужно рассматривать довод пакетов до userspace в случае netmap/dpdk, либо до switchdev в случае kernel. Фраза "чем попытка переложить на процессор " непонятна, где по вашему выполняется логика switchdev?
Если смотреть, на дальнейшую обработку с точки зрения удобства использования, я соглашусь, что использовать решение уже работающее в kernel проще, чем писать тоже самое с нуля для netmap/DPDK, но:
* кто сказал что для netmap/DPDK нет готовых решений для "умной" обрабоки?
* я не думаю, что писать/отлаживать логику в ядре проще чем в userspace, а значит если нужно будет докрутить switchdev на это скорее всего уйдёт больше времени.
Вот довольно неплохое и перспективное (по моему) решение - https://wiki.fd.io/view/VPP. Сейчас потихоньку его изучаю.
> Задача netmap/DPDK довести пакеты до процессора и вывести их в сеть, говорить,
> что обработка может драмматически падать глупо, так как это не относится
> к функциям netmap/dpdk.От меня ускользает смысл этого аргумента, поскольку именно процессинг пакета и важен, а вовсе не только его получение или отправка.
Окей, мы можем с помощью DPDK и NETMAP быстро принять 40 mpps, например. А дальше их надо как-то классифицировать, обработать в соответствии с QoS и/или сделать изменения в заголовке пакета и отдать дальше - в сеть или приложению. И для этих операций нужно уже существенно больше процессорного времени, чем для простого получения или форвардинга.
Кстати, я несогласен не только с посылом такого аргумента, но и с содержанием: dpdk позволяет и QoS своими средствами делать, и ещё много чего, и работает этот функционал не быстро. Испробовано на собственной шкуре.> В данном случае нужно рассматривать довод пакетов до userspace в случае netmap/dpdk,
> либо до switchdev в случае kernel. Фраза "чем попытка переложить на
> процессор " непонятна, где по вашему выполняется логика switchdev?Именно что логика switchdev выполняется в kernel, но это только программирование железки. Весь процессинг пакета происходит в ASIC.
Это более ограниченная парадигма, чем DPDK или NETMAP, но существенно более производительная и менее энергозатратная.> Если смотреть, на дальнейшую обработку с точки зрения удобства использования, я соглашусь,
> что использовать решение уже работающее в kernel проще, чем писать тоже
> самое с нуля для netmap/DPDK, но:
> * кто сказал что для netmap/DPDK нет готовых решений для "умной" обрабоки?
> * я не думаю, что писать/отлаживать логику в ядре проще чем в
> userspace, а значит если нужно будет докрутить switchdev на это скорее
> всего уйдёт больше времени.DPDK хорошо подходит для, например, load-balancing на уровне приложения - это через switchdev не сделаешь. Однако, для use-case описанного в заголовке статьи, как мне кажется, он бы "зашёл" лучше.
Коллега выше написал, что для дальнейшей обработки нужно искать эффективные решения обработки, одно из них это да: VPP, который работает "над" DPDK. Но это несколько уже другая задача и другая тема для обсуждения.Если switchdev это лишь конфигурирование ASIC то:
1. Что мешает его сконфигурировать его из userspace в стиле DPDK?
2. Это оборудование надо ещё купить.
> ...инженеры BBC обратили внимание...Ожидал подобного внимания от Netflix, Google, ну даже от Facebook, но чтобы от BBC.
>> ...инженеры BBC обратили внимание...
> Ожидал подобного внимания от Netflix, Google, ну даже от Facebook, но чтобы
> от BBC.у netflix есть BSD с netgraph, у Facebook - есть DPDK..
Ждем разработок от pornohab
Как сайт он очень даже хорошо работает. Не хуже ютуба.
Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an...
так новость не про технологии. Тут новость про то что BBC сделала драйвер под linux для netmap.
а у тебя свободная freeBSD по ссылке. им свобода не нужна им нужен только открытых код и что бы под линукс
Не считается, это под FreeBSD. Под ней каждый может 100 Гб пропустить. Я лично около 40 Гб пропускал на предтоповом Core i7 позапрошлого поколения.
и что, прямо 40Гбит/с c tls? ;)
> Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an...ну и где in-kernel tls от netflix в freebsd head?
> ну и где in-kernel tls от netflix в freebsd head?И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем с помощью интелского ISA-L, остальное делается в юзерспейсе.
> We decided to pass in to our new ciphers an array of pointersto encrypt from and to, i.e. an
> iovec. This iovec array wouldbe filled in during the initial setup of the sendfile call, as
> eachpage was setup for I/O, thus eliminating the need for traversinga linked list of mbufs. We
> also redesigned the mbuf allocation routines to have the ability, as allocation occurred, to
> includethis new ”mbuf map”.Улучшенный sendfile вкоммитили, aesni тоже.
>> ну и где in-kernel tls от netflix в freebsd head?
> И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
> с помощью интелского ISA-L, остальное делается в юзерспейсе.Затем, что без него sendfile(2) бесполезен.
> Улучшенный sendfile вкоммитили, aesni тоже.нуну.
>>> ну и где in-kernel tls от netflix в freebsd head?
>> И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
>> с помощью интелского ISA-L, остальное делается в юзерспейсе.
> Затем, что без него sendfile(2) бесполезен.Еще раз, для нечитатетелей:
никакого in-kernel-tls там нет.>> Улучшенный sendfile вкоммитили, aesni тоже.
> нуну.Во-во.
> Еще раз, для нечитатетелей:
> никакого in-kernel-tls там нет.Читаем внимательно, с выражением: "To retain the benefits of the sendfile model while adding TLS functionality, we designed a hybrid TLS scheme whereby session management stays in the application space, but the bulk encryption is inserted into the sendfile data pipeline in the kernel. This extends sendfile to support encrypting data for TLS/SSL connections."
Все шифрование в ядре, менеджмент сессий - в юзерленде. Вопрос в той части, которая делает bulk encryption. Где оно в freebsd head?
У них аудиовидеобридж не взлетел почему-то, теперь вот новое придумали... затейники они там.
А можно такое же, но для звука? :) Чтобы jackd это понимал и работал вне зависимости от ядерных выкрутасов?
Это DirectX для сетевых карт