NETMAP (от Luigi Rizzo). Простой и удобный opensource фреймворк для обработки трафика на скоростях 10Gbit/s или 14 Mpps

[T0R]

Евгений, а вы не сравнивали по производительности netmap с pfring DNA и Intel DPDK?
И второй вопрос, резервирует ли netmap под свои нужды большие страницы (у freebsd вроде superpages называются, аналог hugepages в linux)?

[YevgenyY]

Добрый день

Производительность netmap в сравнении c pfring DNA и Intel DPDK мы не сравнивали. Про Intel DPDK, к сожалению, ничего не могу сказать, не работал, судя по описанию — очень круто. Что касается pfring DNA и netmap, они используют похожие, точнее почти одинаковые техники работы с пакетами, соответственно предполагаю, что производительность будет, тоже, одинаковой. Авторы pfring (Luca Deri) и netmap (Luigi Rizzo), кстати, хорошо знают друг друга и вот ниже комментарий Luca Deri относительно производительности pfring и nemap.

Even if DNA and netmap have been developed in totally independent ways, they solve the same problem: how to move packets back/forth a network adapter without using too many CPU cycles. And I believe it’s no surprise that the performance of DNA and netmap is basically the same.
Источник: www.ntop.org/pf_ring/dna-vs-netmap/

По поводу superpages. Netmap, при инициализации, использует свой собственный аллокатор, который выделяет непрерывную область физической памяти для всех необходимых ему для работы структур данных. Ниже фрагмент кода:

static int
netmap_memory_init(void)
{
//...
          buf = contigmalloc(sz + extra_sz,
           M_NETMAP,
           M_WAITOK | M_ZERO,
           0, /* low address */
           -1UL, /* high address */
           PAGE_SIZE, /* alignment */
           0 /* boundary */
          );

//...
}

В результате такого подхода, для работы с любой структурой данных, включая пакетные буферы, используется указатель на начало выделенной области и смещение (offset). Такая техника показывает очень высокое быстродействие. Соответственно, superpages netmap не использует, т.к. он сам делает один большой superpage для себя.

[flx]

логично. весь бенефит только в удобности идеологии фреймворка для конкретных целей.
а рецепт один — zerocopy all the way и не делать лишних телодвижений там где это не нужно.

[izard]

>superpages netmap не использует, т.к. он сам делает один большой superpage для себя.
А CPU DTLB кэш в курсе, что это один большой кэш, а не много 4-килобайтовых страничек, которые идут подряд, но все равно занимают место в DTLB кэше?

[T0R]

Ну если используется техника с оффсетами, то TLB будет транслировать только один виртуальный адрес, указатель на начало. Оффсеты что для физических, что для виртуальных адресов при условии непрерывной области памяти должны быть одинаковыми. Так что вымывания tlb кеша быть не должно.
Другое дело что использование huge/super pages будет все же оптимальнее. Единственный плюс данного подхода — не все цпу умеют большие страницы. (См /proc/cpuinfo, где флаг pse — 2М страницы; pdpe1gb — 1G страницы)

[flx]

Привет, а сколько получилось классического SYN flood удержать на тестовой конфигурации?

[YevgenyY]

Привет, рад видеть твой коммент!

На этот вопрос не ответить в коротко, т.к. слишком много вещей требуется охватить, чтобы ответ не показался кому-либо голословным. Это в первую очередь такие вещи как:
— используемые механизмы фильтрации (syncookie, pps лимиты, другие лимиты, tcpsplicing, др...)
— схема фильтрации, т.е. каков алгоритм прохождения пакета через фильтры
— параметры synflood (кол-во новых ip с которых идёт synflood в сек., количество одновременных реальных сессий в сек, количество
новых реальных сессий в сек. и др.)
— параметры качества фильтрации: для новых сессий, для уже открытых сессий

В лаборатории получатся разогнать фильтрацию synflood на одном 10Gbit/s порту до 12-13Mpps при потоке реальных сессий порядка 500K/s. Стек TCP/IP в процессе не участвует, трафик проходит с одного интерфейса на другой через netmap.

Есть идея подготовить в отдельной статье результаты тестов, в которых показать производительность при изменении количества одновременных сессий, количества новых реальных сессий в секунду и/или изменении параметров synflood. Посмотрим.

[flx]

спасибо за развернутый ответ.
да, бенчмарки интересны. собственно основной вопрос был про то почему везде TX на графиках и так мало RX.

а сами карточки на предмет фильтрации и встроенные в них фильтры дергали?

[YevgenyY]

IMHO в случае TX больше наглядности.

Встроенные фильтры не трогали. Кстати, netmap здорово изменился с декабря 2012 года. В следующий раз, сделаем апдейт по этим изменениям.

[ruikarikun]

С интересом почитал бы про новейшую историю развития netmap.

[0din]

Рад видеть Евгения на хабре. Несмотря на то, что статья аккумулирует практически все, что написано Луиджи, спасибо за систематизацию и перевод. Если последние пару лет все anti-ddos вендоры и сервисы рапортовали об интелектуализации ddos-атак и увелечении % L7, то после непрекращающейся волны dns-amplification атак нам стоит ожидать L3-4 флуд с использованием netmap/dpdk/etc, что не может не беспокоить. Нужно дать пару месяцев на освоение и результаты мы ощутим на себе. При этом масштабироваться так же быстро, как атакующим — не тривиально. Имхо, подобные статьи впервую очередь способствуют развитию инструментария атакующих, а не тех кто использует их в мирных целях.

[phprus]

Жаждущий жить в условиях средневековой инквизиции пусть живет в средневековье во всех сферах жизни.

подобные статьи впервую очередь способствуют развитию инструментария атакующих, а не тех кто использует их в мирных целях.

Борьба с ветряными мельницамизнаниями еще никогда ни к чему хорошему не приводила.

[SysManOne]

Как сделать на NETMAP RSS ?