Size: a a a

2019 November 15

F

Fd in ntwrk
читай про sr-iov
источник

DI

Denis Init in ntwrk
без него VPP вообще не взлетит
источник

F

Fd in ntwrk
ну а если будет dpdk, само собой не нужен тебе sr-iov
источник

VK

Vladimir Komendant in ntwrk
Denis вот тебе на сон грядущий
источник

VK

Vladimir Komendant in ntwrk
Dark Packets and the end of Network Scaling

В продолжение графика. В University of California San Diego изучили проблему влияния времени доступа к DRAM на вероятность потери сетевых данных.
Известно, что inter-packet gap для 100GbE около 5.2 нс, а время доступа к DRAM - 100 нс. Учитывая то, что нет возможности вручную выделять себе on-chip LLC (L3 cache) на CPU, то кеширование происходило автоматически и с временем доступа порядка 12 нс.
Даже при ипользованием Intel DDIO и DMA из NIC в L3 cache, получается существенное количество cache-miss, что в свою очередь приводит к необходимости задействования значительно более медленной DRAM. При обозначенных ранее ТТХ DRAM это ожидаемо приводит к переполнению аппаратных и программных очередей и сбросу пакетов, называемых в статье - Dark Packets. Обойти проблему попытались простым путем - распараллелить пакеты между ядрами процессора, но такой метод оказался немасштабируемым: для 100Gbps нужно 20 физических ядер, а для 400Gb/s уже 79.

В попытках решить проблемы был придуман и имплементирован так называемый CacheBuilder API, использующий Intel Cache Allo-cation Tool APIs и современные инструкций Intel процессоров, в следствие чего удалось в явной форме выделить под приложение часть LLC (L3 cache) и разместить в нём LPM, Hash и exact-match таблицы. В качестве примера используются процессор Xeon E5-2650v5 c 30MB LLC и DPDK приложение для L3 forwarding. Это позволило добиться 40Gb line rate без потерь пакетов размеров 192 байт уже на двух ядрах при задействовании 24MB кэша.

Аналогичный подход мы видим и в NPU современных сетевых вендоров, где есть "быстрый" on-chip SRAM и "медленный" off-chip DRAM.

Хорошо описанная проблематика, много тестов и графиков, характеризующие степени зависимости между скоростью канала, размером пакетов, количеством ядер, количеством обращений к DRAM, промахов кэша и прочим - это всё про прилагаемый PDF.

https://www.sysnet.ucsd.edu/~voelker/pubs/darkpackets-ancs18.pdf
источник

s

sexst in ntwrk
И можно парочку десяток влегкую поиметь. Мы, в общем-то, упирались в то, что пустые pci-e слоты закончились, а имеющиеся были в полку утилизированы.
источник

F

Fd in ntwrk
Vladimir Komendant
Dark Packets and the end of Network Scaling

В продолжение графика. В University of California San Diego изучили проблему влияния времени доступа к DRAM на вероятность потери сетевых данных.
Известно, что inter-packet gap для 100GbE около 5.2 нс, а время доступа к DRAM - 100 нс. Учитывая то, что нет возможности вручную выделять себе on-chip LLC (L3 cache) на CPU, то кеширование происходило автоматически и с временем доступа порядка 12 нс.
Даже при ипользованием Intel DDIO и DMA из NIC в L3 cache, получается существенное количество cache-miss, что в свою очередь приводит к необходимости задействования значительно более медленной DRAM. При обозначенных ранее ТТХ DRAM это ожидаемо приводит к переполнению аппаратных и программных очередей и сбросу пакетов, называемых в статье - Dark Packets. Обойти проблему попытались простым путем - распараллелить пакеты между ядрами процессора, но такой метод оказался немасштабируемым: для 100Gbps нужно 20 физических ядер, а для 400Gb/s уже 79.

В попытках решить проблемы был придуман и имплементирован так называемый CacheBuilder API, использующий Intel Cache Allo-cation Tool APIs и современные инструкций Intel процессоров, в следствие чего удалось в явной форме выделить под приложение часть LLC (L3 cache) и разместить в нём LPM, Hash и exact-match таблицы. В качестве примера используются процессор Xeon E5-2650v5 c 30MB LLC и DPDK приложение для L3 forwarding. Это позволило добиться 40Gb line rate без потерь пакетов размеров 192 байт уже на двух ядрах при задействовании 24MB кэша.

Аналогичный подход мы видим и в NPU современных сетевых вендоров, где есть "быстрый" on-chip SRAM и "медленный" off-chip DRAM.

Хорошо описанная проблематика, много тестов и графиков, характеризующие степени зависимости между скоростью канала, размером пакетов, количеством ядер, количеством обращений к DRAM, промахов кэша и прочим - это всё про прилагаемый PDF.

https://www.sysnet.ucsd.edu/~voelker/pubs/darkpackets-ancs18.pdf
> современные инструкций Intel процессоров
источник

DI

Denis Init in ntwrk
sexst
И можно парочку десяток влегкую поиметь. Мы, в общем-то, упирались в то, что пустые pci-e слоты закончились, а имеющиеся были в полку утилизированы.
пиши в ЛС если че ) есть о чем думаю перепи..ть
источник

s

sexst in ntwrk
Vladimir Komendant
Dark Packets and the end of Network Scaling

В продолжение графика. В University of California San Diego изучили проблему влияния времени доступа к DRAM на вероятность потери сетевых данных.
Известно, что inter-packet gap для 100GbE около 5.2 нс, а время доступа к DRAM - 100 нс. Учитывая то, что нет возможности вручную выделять себе on-chip LLC (L3 cache) на CPU, то кеширование происходило автоматически и с временем доступа порядка 12 нс.
Даже при ипользованием Intel DDIO и DMA из NIC в L3 cache, получается существенное количество cache-miss, что в свою очередь приводит к необходимости задействования значительно более медленной DRAM. При обозначенных ранее ТТХ DRAM это ожидаемо приводит к переполнению аппаратных и программных очередей и сбросу пакетов, называемых в статье - Dark Packets. Обойти проблему попытались простым путем - распараллелить пакеты между ядрами процессора, но такой метод оказался немасштабируемым: для 100Gbps нужно 20 физических ядер, а для 400Gb/s уже 79.

В попытках решить проблемы был придуман и имплементирован так называемый CacheBuilder API, использующий Intel Cache Allo-cation Tool APIs и современные инструкций Intel процессоров, в следствие чего удалось в явной форме выделить под приложение часть LLC (L3 cache) и разместить в нём LPM, Hash и exact-match таблицы. В качестве примера используются процессор Xeon E5-2650v5 c 30MB LLC и DPDK приложение для L3 forwarding. Это позволило добиться 40Gb line rate без потерь пакетов размеров 192 байт уже на двух ядрах при задействовании 24MB кэша.

Аналогичный подход мы видим и в NPU современных сетевых вендоров, где есть "быстрый" on-chip SRAM и "медленный" off-chip DRAM.

Хорошо описанная проблематика, много тестов и графиков, характеризующие степени зависимости между скоростью канала, размером пакетов, количеством ядер, количеством обращений к DRAM, промахов кэша и прочим - это всё про прилагаемый PDF.

https://www.sysnet.ucsd.edu/~voelker/pubs/darkpackets-ancs18.pdf
В кеш conntrack один хрен не влезет, а это самое толстожопое из операций. Хотя даже lookup ускорить дало бы свой выхлоп.
источник

VK

Vladimir Komendant in ntwrk
Fd
> современные инструкций Intel процессоров
писателей у нас тут нет
источник

F

Fd in ntwrk
Vladimir Komendant
писателей у нас тут нет
я про "современный" и "процессор".
источник

F

Fd in ntwrk
ТЗ не выполняется уже.
источник

s

sexst in ntwrk
Последнее ещё: nftables попробовать. Там advanced конструкции в плане nat. Можно много записей в одно правило ебануть
источник

F

Fd in ntwrk
и немного о прекрасном
источник

DI

Denis Init in ntwrk
ТЗ и не выполнишь тут слишком сильно пока Linux Network Stack не возьмут себя в руки, а они и не возьмут, потому что это не выгодно тот же Intel их донатит сильно, не могут они в укор себе работать
источник

F

Fd in ntwrk
Реддитор(jimmyoneshot) обнаружил, что в ПК-версии Red Dead Redemption 2 Артур быстрее устаёт и худеет при более высоком FPS.

Чтобы проверить свою гипотезу, jimmyoneshot запускал игру с разными настройками. В одном случае — со 120 кадрами, а в другом — с 30. В обоих тестах он ел по четыре стейка в день. В итоге при 120 кадрах Артур всего за 10 дней достиг своего минимального веса — «-7,5» на шкале в меню. А на 30 FPS четыре стейка в сутки помогали Артуру набирать вес, а не терять его.
источник

s

sexst in ntwrk
И это будет реально в один байткод собираться и в один хук в netfilter вызываться.
источник

DI

Denis Init in ntwrk
агааааа, они просто не развивают эту технологию по понятным причинам
источник

s

sexst in ntwrk
Т.е. меньше шансов вымывания кеша опять же
источник

VK

Vladimir Komendant in ntwrk
Fd
Реддитор(jimmyoneshot) обнаружил, что в ПК-версии Red Dead Redemption 2 Артур быстрее устаёт и худеет при более высоком FPS.

Чтобы проверить свою гипотезу, jimmyoneshot запускал игру с разными настройками. В одном случае — со 120 кадрами, а в другом — с 30. В обоих тестах он ел по четыре стейка в день. В итоге при 120 кадрах Артур всего за 10 дней достиг своего минимального веса — «-7,5» на шкале в меню. А на 30 FPS четыре стейка в сутки помогали Артуру набирать вес, а не терять его.
у меня так брат умер
источник