F
читай про sr-iov
Size: a a a
2019 November 15
DI
без него VPP вообще не взлетит
F
ну а если будет dpdk, само собой не нужен тебе sr-iov
VK
Denis вот тебе на сон грядущий
VK
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
В продолжение графика. В 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
F
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
В продолжение графика. В 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 процессоров
s
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
В продолжение графика. В 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
Fd
> современные инструкций Intel процессоров
писателей у нас тут нет
F
писателей у нас тут нет
я про "современный" и "процессор".
F
ТЗ не выполняется уже.
F
и немного о прекрасном
DI
ТЗ и не выполнишь тут слишком сильно пока Linux Network Stack не возьмут себя в руки, а они и не возьмут, потому что это не выгодно тот же Intel их донатит сильно, не могут они в укор себе работать
F
Реддитор(jimmyoneshot) обнаружил, что в ПК-версии Red Dead Redemption 2 Артур быстрее устаёт и худеет при более высоком FPS.
Чтобы проверить свою гипотезу, jimmyoneshot запускал игру с разными настройками. В одном случае — со 120 кадрами, а в другом — с 30. В обоих тестах он ел по четыре стейка в день. В итоге при 120 кадрах Артур всего за 10 дней достиг своего минимального веса — «-7,5» на шкале в меню. А на 30 FPS четыре стейка в сутки помогали Артуру набирать вес, а не терять его.
DI
агааааа, они просто не развивают эту технологию по понятным причинам
VK
Fd
Реддитор(jimmyoneshot) обнаружил, что в ПК-версии Red Dead Redemption 2 Артур быстрее устаёт и худеет при более высоком FPS.
Чтобы проверить свою гипотезу, jimmyoneshot запускал игру с разными настройками. В одном случае — со 120 кадрами, а в другом — с 30. В обоих тестах он ел по четыре стейка в день. В итоге при 120 кадрах Артур всего за 10 дней достиг своего минимального веса — «-7,5» на шкале в меню. А на 30 FPS четыре стейка в сутки помогали Артуру набирать вес, а не терять его.
у меня так брат умер