The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Корпорация BBC открыла наработки по обработке сетевых пакетов в обход ядра Linux

04.05.2018 12:17

Британская вещательная корпорация (BBC) открыла код, разработанный в рамках проекта IP Studio для повышения пропускной способности систем потокового вещания через IP-сети. Разработка базируется на фреймворке Netmap и ориентирована на повышение пропускной способности в конфигурациях с 100-гигабитными каналами связи за счёт применения техники обхода штатных обработчиков пакетов сетевого стека ядра ('kernel bypass') и предоставления средств для прямой передачи пакетов между приложениями и сетевым оборудованием.

В ходе экспериментов с разработкой программного продукта для потокового вещания инженеры BBC обратили внимание, что узким местом при обработке очень большого числа сетевых пакетов являются операции копирования пакетов в различные области памяти, которые в процессе обработки через стандартную систему сокетов производятся несколько раз. Использование Netmap помогло сократить число операций копирования за счёт прямой передачи сразу нескольких пакетов сетевой карте. В качестве сетевого адаптера в BBC использовался Mellanox ConnectX-4, для которого имеется открытый драйвер для ядра Linux, но отсутствует поддержка в Netmap.

На основе имеющегося драйвера разработчики BBC подготовили код для поддержки сетевых адаптеров Mellanox в Netmap и добились производительности на уровне 80 гигабит в секунду при однопоточном тестировании. В итоге для включения в основной состав проекта Netmap был предложен новый драйвер mlx5 с поддержкой прямого взаимодействия c 10/25/40/50/100-гигабитными сетевыми адапетрами Mellanox ConnectX-4 и ConnectX-5.

  1. Главная ссылка к новости (https://www.bbc.co.uk/rd/blog/...)
  2. OpenNews: Открыт код Syncookied, системы защиты от DDoS-атак
  3. OpenNews: CloudFlare применил NetMap для повышения скорости обработки пакетов в Linux
  4. OpenNews: Релиз FastNetMon 1.1.2, открытого решения по обнаружению DDoS-атак
  5. OpenNews: Эксперимент по реализации http-сервера, взаимодействующего напрямую с сетевым адаптером
  6. OpenNews: Выпуск DPDK 18.02, фреймворка для высокопроизводительных сетевых приложений
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48548-netmap
Ключевые слова: netmap, bbc, kerel, network
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (53) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Андрей (??), 12:19, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Наконец-то!
     
     
  • 2.2, Владимир (??), 12:23, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если не секрет, вам это зачем? Что за сфера?
     
     
  • 3.8, ТТТ (?), 12:36, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потоковое вещание, не?
     
  • 3.10, asdf (?), 12:45, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как один из примеров это фильтрация DDoS атак
     
     
  • 4.22, Pahanivo (ok), 13:34, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
    > один из примеров это фильтрация DDoS атак

    речь то вроде не о фильтрации на таких скоростях ....

     
     
  • 5.24, asdf (?), 13:55, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
    >> один из примеров это фильтрация DDoS атак
    > речь то вроде не о фильтрации на таких скоростях ....

    Ну про проброс вроде обсудили выше, тут добавил ещё вариант применения.

     

  • 1.4, asdf (?), 12:30, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    netmap шаг назад, зачем он нужен когда есть dpdk.
     
     
  • 2.7, F (?), 12:35, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Они сделали так, но вас никто не сдерживает что-то лучшее подготовить и предложить сообществу!
     
     
  • 3.9, asdf (?), 12:41, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже давно сделано, dpdk прокачивает 94 GbE на dpdk 17.02, погугли
     
     
  • 4.33, pavlinux (ok), 16:20, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >  погугли

    Диванный теоретик, за себя отвечай. Покажи замеры.

     
  • 2.12, nuclight (??), 12:46, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.
     
     
  • 3.14, asdf (?), 12:50, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.

    Вы вышли из криосна? DPDK уже давно поддерживает не только intel. В netmap нет поддержки SMP, например, как и почти всего остального.

     
     
  • 4.16, letsmac (ok), 13:01, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>В netmap нет поддержки SMP,

    А зачем SMP он там вообще нужен? Если цель - минимизация посрелников? Разные коннекты по разным процессорам и так разбегутся.

     
     
  • 5.23, asdf (?), 13:36, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>>В netmap нет поддержки SMP,
    > А зачем SMP он там вообще нужен? Если цель - минимизация посрелников?
    > Разные коннекты по разным процессорам и так разбегутся.

    Если шатные методы разделения потока оказываются не приемлимы, а это частая ситуация, так как обычно аппаратно поддерживается делёжка только по IP адресу и/или порту, то делить приходится программными методами, а это значит что для netmap приходится писать набор велосипедов, тогда как в dpdk всё из коробки.

     
  • 3.29, воткакбы (?), 15:07, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > сетевыми адапетрами Mellanox ConnectX-4 и ConnectX-5.

    Так оно как бы тоже.

     
  • 2.31, sdog (ok), 15:54, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не пользуй
     
  • 2.53, freehck (ok), 21:04, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > netmap шаг назад, зачем он нужен когда есть dpdk.

    Ну так потому BBC и открыли код, наверное. :)

     
     
  • 3.60, Ne01eX (ok), 05:19, 11/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ...Или наступили на грабли, которые сами не в состоянии исправить...
     

  • 1.5, Ан (??), 12:30, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Для чего они выпускают 100Гбит адаптеры, если даже хитросделанный кастомный драйвер под линукс не могет столько прокачать?
     
     
  • 2.6, Аниним (?), 12:32, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Потому что они работают на тех ОС, которые таки могут его прокачать.
     
     
  • 3.13, asdf (?), 12:47, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Потому что они работают на тех ОС, которые таки могут его прокачать.

    Netmap есть под windows ;-)

     
  • 3.28, Аноним (-), 14:42, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что они работают на тех ОС, которые таки могут его прокачать.

    То есть ни на каких? То есть 1 гигабит это маркетинговый ход? Я так и знал.

     
  • 3.38, Аноним (-), 17:36, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому что они работают на тех ОС, которые таки могут его прокачать.

    Т.е. на сферическо-вакуумных.

     
     
  • 4.44, Аноним (-), 20:33, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >>Потому что они работают на тех ОС, которые таки могут его прокачать.
    > Т.е. на сферическо-вакуумных.

    https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appl
    Вы уж определитесь - то бзда рипнутая и никому не нужная, то она сферическо-вакуумная.

     
     
  • 5.49, angra (ok), 01:05, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Там достигнута была скорость 90Gbps и для этого пришлось использовать огромную кучу костылей и подпорок. Хотя надо признать, что многие из них были связаны не с сетевым стеком.
     
  • 2.32, Аноним (-), 16:00, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Речь про 80 гбит на один поток в новости.
     

  • 1.11, Аноним (-), 12:46, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Из оригинала не очень понятно каким был предел передачи без netmap. Проблема то понятная, но интересно на сколько решение улучшило положение вещей.
     
     
  • 2.15, asdf (?), 12:55, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Из оригинала не очень понятно каким был предел передачи без netmap. Проблема
    > то понятная, но интересно на сколько решение улучшило положение вещей.

    Из новости понятно только то, что они добавили поддержку ещё одного вендора и всё. Улучшило так: не работало никак, стало работать.

     
     
  • 3.18, Crazy Alex (ok), 13:03, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
     
     
  • 4.19, asdf (?), 13:10, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке

    Обычно около 1Mpps на 1 процессоре (+- конечно, процессоры разные) при 100% загрузки. На dpdk около 20-100Mpps, netmap обычно показывает схожую производительность.

     
     
  • 5.20, Аноним (-), 13:16, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А не пробовали offload включить и слегка тюнить афинити ?
     
     
  • 6.26, asdf (?), 14:20, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Там как не крути, всё равно мы упираемся в копирование, единственное что может хоть как-то спасти ситуацию, на мой взгляд, это packetv4+zc, который уже есть в наработках.
     
  • 6.27, Аноним (-), 14:25, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://youtu.be/sVdVVMOjtoI?t=316
    https://people.netfilter.org/hawk/presentations/nfws2014/dp-accel-10G-challeng

    Даже сискол это дорого уже на 10GbE

     
  • 5.34, anonymous (??), 16:23, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
    > Обычно около 1Mpps на 1 процессоре (+- конечно, процессоры разные) при 100%
    > загрузки. На dpdk около 20-100Mpps, netmap обычно показывает схожую производительность.

    DPDK неплохая технология, но называть конкретные цифры - это чистой воды маркетинг.
    Да, тупой L2 форвардинг из порта в порт может и будет 20-100 mpps, но как только добавляется какая-то "умная" обработка, производительность драматически падает, иногда в 10 раз. И это при том, что для DPDK нужна куча приседаний и утилизация ядер всегда "в полку".
    switchdev мне кажется куда более перспективной технологией, чем попытка переложить на процессор то, что на нём не надо обрабатывать.

     
     
  • 6.36, asdf (?), 17:15, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Задача netmap/DPDK довести пакеты до процессора и вывести их в сеть, говорить, что обработка может драмматически падать глупо, так как это не относится к функциям netmap/dpdk.

    В данном случае нужно рассматривать довод пакетов до userspace в случае netmap/dpdk, либо до switchdev в случае kernel. Фраза "чем попытка переложить на процессор " непонятна, где по вашему выполняется логика switchdev?

    Если смотреть, на дальнейшую обработку с точки зрения удобства использования, я соглашусь, что использовать решение уже работающее в kernel проще, чем писать тоже самое с нуля для netmap/DPDK, но:
    * кто сказал что для netmap/DPDK нет готовых решений для "умной" обрабоки?
    * я не думаю, что писать/отлаживать логику в ядре проще чем в userspace, а значит если нужно будет докрутить switchdev на это скорее всего уйдёт больше времени.


     
     
  • 7.42, An (??), 19:55, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот довольно неплохое и перспективное (по моему) решение - https://wiki.fd.io/view/VPP. Сейчас потихоньку его изучаю.  
     
  • 7.50, anonymous (??), 18:26, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    От меня ускользает смысл этого аргумента, поскольку именно процессинг пакета и в... большой текст свёрнут, показать
     
     
  • 8.52, asdf (?), 19:49, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Коллега выше написал, что для дальнейшей обработки нужно искать эффективные реше... текст свёрнут, показать
     

  • 1.17, Ilya Indigo (ok), 13:02, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > ...инженеры BBC обратили внимание...

    Ожидал подобного внимания от Netflix, Google, ну даже от Facebook, но чтобы от BBC.

     
     
  • 2.21, Аноним (-), 13:17, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> ...инженеры BBC обратили внимание...
    > Ожидал подобного внимания от Netflix, Google, ну даже от Facebook, но чтобы
    > от BBC.

    у netflix есть BSD с netgraph, у Facebook - есть DPDK..

     
  • 2.25, Алконим (?), 13:56, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +18 +/
    Ждем разработок от pornohab
     
     
  • 3.48, Вареник (?), 00:50, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как сайт он очень даже хорошо работает. Не хуже ютуба.
     

  • 1.30, Dmitry (??), 15:12, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appl
     
     
  • 2.35, Anonim (??), 16:40, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так новость не про технологии. Тут новость про то что BBC сделала драйвер под linux для netmap.
    а у тебя свободная freeBSD по ссылке. им свобода не нужна им нужен только открытых код и что бы под линукс
     
  • 2.46, vantoo (ok), 21:52, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не считается, это под FreeBSD. Под ней каждый может 100 Гб пропустить. Я лично около 40 Гб пропускал на предтоповом Core i7 позапрошлого поколения.
     
     
  • 3.54, Netmapguy (?), 03:23, 06/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    и что, прямо 40Гбит/с  c tls? ;)


     
  • 2.55, Netmapguy (?), 03:24, 06/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appl

    ну и где in-kernel tls от netflix в freebsd head?

     
     
  • 3.56, Аноним (-), 16:10, 06/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ну и где 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 тоже.

     
     
  • 4.57, DPDKguy (?), 17:23, 07/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> ну и где in-kernel tls от netflix в freebsd head?
    > И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
    > с помощью интелского ISA-L, остальное делается в юзерспейсе.

    Затем, что без него sendfile(2) бесполезен.


    > Улучшенный sendfile вкоммитили, aesni тоже.

    нуну.

     
     
  • 5.58, Аноним (-), 18:17, 07/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> ну и где in-kernel tls от netflix в freebsd head?
    >> И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
    >> с помощью интелского ISA-L, остальное делается в юзерспейсе.
    > Затем, что без него sendfile(2) бесполезен.

    Еще раз, для нечитатетелей:
    никакого in-kernel-tls там нет.

    >> Улучшенный sendfile вкоммитили, aesni тоже.
    > нуну.

    Во-во.


     
     
  • 6.59, DPDKguy (?), 13:33, 08/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Еще раз, для нечитатетелей:
    > никакого 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?


     

  • 1.41, IdeaFix (ok), 19:54, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У них аудиовидеобридж не взлетел почему-то, теперь вот новое придумали... затейники они там.
     
  • 1.43, Константавр (ok), 20:02, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А можно такое же, но для звука? :) Чтобы jackd это понимал и работал вне зависимости от ядерных выкрутасов?
     
  • 1.45, Штунц (?), 20:35, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это DirectX для сетевых карт
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру