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
