| |
| |
| 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 атак
> речь то вроде не о фильтрации на таких скоростях ....
Ну про проброс вроде обсудили выше, тут добавил ещё вариант применения.
| | |
|
|
|
|
| |
| 2.7, F (?), 12:35, 04/05/2018 [^] [^^] [^^^] [ответить]
| +9 +/– |
Они сделали так, но вас никто не сдерживает что-то лучшее подготовить и предложить сообществу!
| | |
| |
| 3.9, asdf (?), 12:41, 04/05/2018 [^] [^^] [^^^] [ответить]
| +/– |
Это уже давно сделано, dpdk прокачивает 94 GbE на dpdk 17.02, погугли
| | |
|
| 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.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 [^] [^^] [^^^] [ответить]
| +/– | |
>Потому что они работают на тех ОС, которые таки могут его прокачать.
Т.е. на сферическо-вакуумных.
| | |
| |
| |
| 5.49, angra (ok), 01:05, 05/05/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Там достигнута была скорость 90Gbps и для этого пришлось использовать огромную кучу костылей и подпорок. Хотя надо признать, что многие из них были связаны не с сетевым стеком.
| | |
|
|
|
|
| 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 обычно показывает схожую производительность.
| | |
| |
| |
| 6.26, asdf (?), 14:20, 04/05/2018 [^] [^^] [^^^] [ответить]
| +/– |
Там как не крути, всё равно мы упираемся в копирование, единственное что может хоть как-то спасти ситуацию, на мой взгляд, это packetv4+zc, который уже есть в наработках.
| | |
|
| 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 на это скорее всего уйдёт больше времени.
| | |
| |
| |
| 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.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.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 это понимал и работал вне зависимости от ядерных выкрутасов?
| | |
|
