Я в целом конечно соглашусь, задача обработки трафика является скорее memory bound, нежели compute bound. Однако в современных ЦПУ не просто так есть префетчинг.
>Условный Cavium ... не занимается пересыланием полной строки кеша при доступе к uint32
странно, а тут https://www.7-cpu.com/cpu/Octeon2.html написано что размер кеш линии 128 байт. Да и кеш имеет место быть. Как так?
Более того, в задаче обработки трафика spatial locality встречается повеместно, так что кеш более чем необходим.
>а вот копаться в том самом хедере
зависит от задачи и реализации. Некоторый код становится очень ветвистым, могут возникнуть проблемы. Частенько решается правильным использованием векторизации.
>сравнивать его поля со структурами в памяти - это дорого для платформ общего применения
опять таки зависит от задачи. Сделать лукап по в4 фул вью - дело <20 тактов.
>Само ядро даже десятилетней платформы х86 может легко обрабатывать на уровне десятков миллионов пакетов на нетривиальном пути, но мгновенно упирается в память.
В неоптимальном коде. Используя префетчинг техники удается сгладить большую латенси памяти. С пропускной способностью проблем пока не встречал. И да, чтобы эффективно префетчить нужно обрабатывать пакеты балком. Это как раз таки выгодно отличает дпдк реализации сетевых функций от реализованый в том же ядре.
> но пакетная часть - она довольно ограничена в контексте параллеливания
просьба пояснить, что является "пакетной частью" ДПДК
>большинство структур там под локами, и также совсем не дружелюбно к деталям памяти
это не так. Большинство структур защищается локами только на control path, data path же локлесс. Так же структуры в основном дружелюбны к памяти, учитываетмся НУМА, для мемпулов учитываются даже ранки памяти.
>но если 100Г+ - то будет больно.
обрабатываю и больше. ЧЯДНТ? :)

ну например терабит ипсека вполне обрабатывается

Это уже достигнутый рубеж

Ок, я отстал от жизни, значит.

дабы не быть голословным, вот
https://builders.intel.com/docs/networkbuilders/3rd-generation-intel-xeon-scalable-processor-achieving-1-tbps-ipsec-with-intel-advanced-vector-1617435344.pdf

Я слабо верю что у Cavium что-то отличное от dram

> Однако в современных ЦПУ не просто так есть префетчинг.
>Условный Cavium ... не занимается пересыланием полной строки кеша при доступе к uint32
странно, а тут https://www.7-cpu.com/cpu/Octeon2.html написано что размер кеш линии 128 байт. Да и кеш имеет место быть. Как так?

Префетчинг и полоса памяти - они довольно ортогональны. Префетчинг делает свое дело, но проблема в том, что если мне нузны 4 байта, я их, конечно, могу префетчить задолго до того, как мне они будут нужны. Но из памяти придет 64 байта вместо четырех, а скорость чтения с конденсаторов за последние 20 лет увеличилось примерно в два раза. Скорость интерфейса модуля памяти - да, увеличился в 50 раз, и мои четыре байта могли бы стать доступными быстрее, если вся транзакция не ждала чтения части строки в 64 байта. Да, эта задержка легко прятается за множеством активных запросов, но тут другая проблема - то, что содедние два поля по 4 байта на физических адресах (уже посте трансляции) лежат рядом, совсем не значит, что они будут рядом на одной стоке, а не в разных банках или группах банков, и надо будет их отдельно открывать.

У того конкретного Кавиума кеш есть - так как это МИПС обсшего применения с парой сбоку прикрученных сетевых интерфейсов. Я под "условным Кавиумом" в воду имел немного более специализированный компонент, для которого процессорное ядро общего пользования является вспомогательным и на прямую не занимается обработкой пакетов - извините, елси такое выражение не было ясным. DNX, например - там система памяти для лукапов реализована как широкая магистраль с короткими циклами (HBM2).

Так большинство памяти большой емкости релаизовано как DRAM, разница в том, что конкретные реализации будут давать кардинально разные параметры и будут предназначены для совсем разных применений. И память для лукапа IPv4, для поиска строки URL, и для сбора статистики удет иметь разную ширину и разную длину одного цикла.

>сравнивать его поля со структурами в памяти - это дорого для платформ общего применения
опять таки зависит от задачи. Сделать лукап по в4 фул вью - дело <20 тактов.

Если только сам лукап - да, около того на х86, и если структуры для лукапа в кеше. Внеочередное исполнение немного амортизирует задержки с памятью, при наличии чего исполнять внеочередно, конечно. И если сами структуры лукапа не мешают кешированию - как пример, DPDK lpm4 в формате 24+8 при небольшом разбросе префиксов (небольшом в том смысле, что они сконцентрированные около малого количества covering префиксов - допустим, несколько кучь /24 внутри разных /16) из-за линейности LPM24 части будет постоянно выбрасывать из кеша для прошлого пакета нужные записи. Предварительная сортировка батча помогает, но более продуктивно оказывается пользовать структуру типа 8-8-8-8 или 12-4-4-4-4-8 или что-то похожее. Но это также не бесплатно - нагрузка на кеш растет из-за раздува самой структуры. Более больно будет, если к лукапу будет еще и сбор детальной статистики - и это может кончится записью 512 бит вместо 48 (для счетчика достаточно, но злой кеш лезет в середину; да, nontemporal записи есть, но память все равно не принимает транзакцию короче 32 байт).

Кстати: векторизация - да, это радость. AVX-512 в массы. :-)

А Линус сказал, что не нужно.)

> но пакетная часть - она довольно ограничена в контексте параллеливания
просьба пояснить, что является "пакетной частью" ДПДК

Пакетная часть - это набор библиотек для копания в хедерах. lpm, acl, и pipeline, плюс части eal, которые нужны для их функционирования.

Так о каких кардинально разных характеристиках речь, если dram memory latency +/- одинакова?

В ядре - почти не нужно. Оно там, кстати, и так есть с давних времен - для узкоспециализированных целей. Но на стороне пользователя AVX-512 вам бесплатно дает увеличение throughput в значимом количестве. Не latency - это противоречило бы законам физики. Линус - он толковый инженер ядра, но не обязательно понимает проблематику поверх ядра.

> AVX-512 вам бесплатно дает увеличение throughput в значимом количестве
Осталось его дождаться на массовых процессорах, а не на специальных вычислителях и некоторых серверных процессорах одной синей компании.

AVX512 выдает такую тепловую и энерго нагрузку, что процессор сразу уходит в throttling.

уже нет

https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html

Это технологическое ограничение. При эволюции процесса эта проблема становится все меньше. ICX на 32-х ядрах пермутацию делает на -17% по сравнению с одним ядром. SKX делал на -48%.

И также лицензии питания понизились у значимой части векторных инструкций.
Не надо надеятся, что это совсем исчезнет - опять, это противоречило-бы законам физики - количество производимой работы то увеличелось.

https://www.phoronix.com/scan.php?page=article&item=rocket-lake-avx512&num=6
это даже не 10е поколение, а 11е. Пропуск тактов идет от теплового пакета: повысили TDP с 65 до 80-95w вот и счастье наступило...