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

Добрый день

Производительность 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 для себя.

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

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

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

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

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

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

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

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