The OpenNET Project / Index page

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



"Корпорация BBC открыла наработки по обработке сетевых пакето..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от opennews (??) on 04-Май-18, 12:19 
Британская вещательная корпорация (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.ru/opennews/art.shtml?num=48548

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от Андрей (??) on 04-Май-18, 12:19 
Наконец-то!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +3 +/
Сообщение от Владимир email(??) on 04-Май-18, 12:23 
Если не секрет, вам это зачем? Что за сфера?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

8. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +2 +/
Сообщение от ТТТ on 04-Май-18, 12:36 
Потоковое вещание, не?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

10. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 12:45 
Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как один из примеров это фильтрация DDoS атак
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

22. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Pahanivo (ok) on 04-Май-18, 13:34 
> Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
> один из примеров это фильтрация DDoS атак

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

24. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 13:55 
>> Любая сфера, где нужно либо форварднуть либо дропнуть хренову кучу трафика, как
>> один из примеров это фильтрация DDoS атак
> речь то вроде не о фильтрации на таких скоростях ....

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

4. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –3 +/
Сообщение от asdf on 04-Май-18, 12:30 
netmap шаг назад, зачем он нужен когда есть dpdk.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +9 +/
Сообщение от F on 04-Май-18, 12:35 
Они сделали так, но вас никто не сдерживает что-то лучшее подготовить и предложить сообществу!
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 12:41 
Это уже давно сделано, dpdk прокачивает 94 GbE на dpdk 17.02, погугли
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

33. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от pavlinux (ok) on 04-Май-18, 16:20 
>  погугли

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

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от nuclight email(??) on 04-Май-18, 12:46 
Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

14. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 12:50 
> Валяй, обоснуй. DPDK ограничен поддерживаемыми сетевухами, например.

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от letsmac (ok) on 04-Май-18, 13:01 
>>В netmap нет поддержки SMP,

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от asdf on 04-Май-18, 13:36 
>>>В netmap нет поддержки SMP,
> А зачем SMP он там вообще нужен? Если цель - минимизация посрелников?
> Разные коннекты по разным процессорам и так разбегутся.

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

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

29. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от воткакбы on 04-Май-18, 15:07 
> сетевыми адапетрами Mellanox ConnectX-4 и ConnectX-5.

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

31. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от sdog (ok) on 04-Май-18, 15:54 
не пользуй
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

53. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от freehck email(ok) on 05-Май-18, 21:04 
> netmap шаг назад, зачем он нужен когда есть dpdk.

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

60. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Ne01eX (ok) on 11-Май-18, 05:19 
...Или наступили на грабли, которые сами не в состоянии исправить...
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

5. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от Ан (??) on 04-Май-18, 12:30 
Для чего они выпускают 100Гбит адаптеры, если даже хитросделанный кастомный драйвер под линукс не могет столько прокачать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +9 +/
Сообщение от Аниним on 04-Май-18, 12:32 
Потому что они работают на тех ОС, которые таки могут его прокачать.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

13. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от asdf on 04-Май-18, 12:47 
> Потому что они работают на тех ОС, которые таки могут его прокачать.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

28. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Аноним (??) on 04-Май-18, 14:42 
> Потому что они работают на тех ОС, которые таки могут его прокачать.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

38. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Аноним (??) on 04-Май-18, 17:36 
>Потому что они работают на тех ОС, которые таки могут его прокачать.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

44. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +8 +/
Сообщение от Аноним (??) on 04-Май-18, 20:33 
>>Потому что они работают на тех ОС, которые таки могут его прокачать.
> Т.е. на сферическо-вакуумных.

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

49. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –2 +/
Сообщение от angra (ok) on 05-Май-18, 01:05 
Там достигнута была скорость 90Gbps и для этого пришлось использовать огромную кучу костылей и подпорок. Хотя надо признать, что многие из них были связаны не с сетевым стеком.
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

32. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Аноним (??) on 04-Май-18, 16:00 
Речь про 80 гбит на один поток в новости.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

11. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +3 +/
Сообщение от Аноним (??) on 04-Май-18, 12:46 
Из оригинала не очень понятно каким был предел передачи без netmap. Проблема то понятная, но интересно на сколько решение улучшило положение вещей.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от asdf on 04-Май-18, 12:55 
> Из оригинала не очень понятно каким был предел передачи без netmap. Проблема
> то понятная, но интересно на сколько решение улучшило положение вещей.

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

18. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Crazy Alex (ok) on 04-Май-18, 13:03 
Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 13:10 
> Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от Аноним (??) on 04-Май-18, 13:16 
А не пробовали offload включить и слегка тюнить афинити ?
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

26. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 04-Май-18, 14:20 
Там как не крути, всё равно мы упираемся в копирование, единственное что может хоть как-то спасти ситуацию, на мой взгляд, это packetv4+zc, который уже есть в наработках.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от Аноним (??) on 04-Май-18, 14:25 
https://youtu.be/sVdVVMOjtoI?t=316
https://people.netfilter.org/hawk/presentations/nfws2014/dp-...

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

34. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +2 +/
Сообщение от anonymous (??) on 04-Май-18, 16:23 
>> Если я правильно понимаю, аноним поинтересовался, сколько было на штатном линуксовом стеке
> Обычно около 1Mpps на 1 процессоре (+- конечно, процессоры разные) при 100%
> загрузки. На dpdk около 20-100Mpps, netmap обычно показывает схожую производительность.

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

36. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от asdf on 04-Май-18, 17:15 
Задача netmap/DPDK довести пакеты до процессора и вывести их в сеть, говорить, что обработка может драмматически падать глупо, так как это не относится к функциям netmap/dpdk.

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

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


Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

42. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от An (??) on 04-Май-18, 19:55 
Вот довольно неплохое и перспективное (по моему) решение - https://wiki.fd.io/view/VPP. Сейчас потихоньку его изучаю.  
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

50. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от anonymous (??) on 05-Май-18, 18:26 
> Задача 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 описанного в заголовке статьи, как мне кажется, он бы "зашёл" лучше.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

52. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от asdf on 05-Май-18, 19:49 
Коллега выше написал, что для дальнейшей обработки нужно искать эффективные решения обработки, одно из них это да: VPP, который работает "над" DPDK. Но это несколько уже другая задача и другая тема для обсуждения.

Если switchdev это лишь конфигурирование ASIC то:
1. Что мешает его сконфигурировать его из userspace в стиле DPDK?
2. Это оборудование надо ещё купить.

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

17. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от Ilya Indigo (ok) on 04-Май-18, 13:02 
> ...инженеры BBC обратили внимание...

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от Аноним (??) on 04-Май-18, 13:17 
>> ...инженеры BBC обратили внимание...
> Ожидал подобного внимания от Netflix, Google, ну даже от Facebook, но чтобы
> от BBC.

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

25. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +18 +/
Сообщение от Алконим on 04-Май-18, 13:56 
Ждем разработок от pornohab
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

48. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от Вареник on 05-Май-18, 00:50 
Как сайт он очень даже хорошо работает. Не хуже ютуба.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

30. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +7 +/
Сообщение от Dmitry (??) on 04-Май-18, 15:12 
Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +1 +/
Сообщение от Anonim (??) on 04-Май-18, 16:40 
так новость не про технологии. Тут новость про то что BBC сделала драйвер под linux для netmap.
а у тебя свободная freeBSD по ссылке. им свобода не нужна им нужен только открытых код и что бы под линукс
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

46. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +2 +/
Сообщение от vantoo (ok) on 04-Май-18, 21:52 
Не считается, это под FreeBSD. Под ней каждый может 100 Гб пропустить. Я лично около 40 Гб пропускал на предтоповом Core i7 позапрошлого поколения.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

54. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Netmapguy on 06-Май-18, 03:23 
и что, прямо 40Гбит/с  c tls? ;)


Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

55. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –1 +/
Сообщение от Netmapguy on 06-Май-18, 03:24 
> Неосиляторы, учитесь у Netflix https://medium.com/netflix-techblog/serving-100-gbps-from-an...

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

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

56. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +2 +/
Сообщение от Аноним (??) on 06-Май-18, 16:10 
> ну и где 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 тоже.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

57. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от DPDKguy on 07-Май-18, 17:23 
>> ну и где in-kernel tls от netflix в freebsd head?
> И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
> с помощью интелского ISA-L, остальное делается в юзерспейсе.

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


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

нуну.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

58. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Аноним (??) on 07-Май-18, 18:17 
>>> ну и где in-kernel tls от netflix в freebsd head?
>> И зачем он там сдался? В ядре только шифруют отсылаемые данные, причем
>> с помощью интелского ISA-L, остальное делается в юзерспейсе.
> Затем, что без него sendfile(2) бесполезен.

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

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

Во-во.


Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

59. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от DPDKguy on 08-Май-18, 13:33 
> Еще раз, для нечитатетелей:
> никакого 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?


Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

41. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от IdeaFix email(ok) on 04-Май-18, 19:54 
У них аудиовидеобридж не взлетел почему-то, теперь вот новое придумали... затейники они там.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  –2 +/
Сообщение от Константавр (ok) on 04-Май-18, 20:02 
А можно такое же, но для звука? :) Чтобы jackd это понимал и работал вне зависимости от ядерных выкрутасов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Корпорация BBC открыла наработки по обработке сетевых пакето..."  +/
Сообщение от Штунц on 04-Май-18, 20:35 
Это DirectX для сетевых карт
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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