Сетевой анализатор на CUDA

продолжаем перепубликацию с GPGPU.ORG

Gnort: High Performance Network Intrusion Detection Using Graphics Processors: модифицированный Snort, обработка паттернов делается на GPU (NVidia/CUDA).

Если честно, то статья совершенно не зацепила. "Взяли известные алгоритмы, имплементировали на CUDA, померяли производительность на слабом оборудовании, намеряли 2-2.3-кратное ускорение". Студенческая курсовая работа, ну может быть бакалаврский диплом. С другой стороны, как источник библиографических данных этот текст вполне можно использовать.

Достаточно понятно, что сетевой анализатор - неудобная штука для реализации на видеокарте: если поток маленький, то можно и на CPU, а если большой - то задержки на загрузку данных в видеокарту испортят всю малину. Какая-то разумность у таких приложений появляется только если CPU очевидно не справляется и задержка на обработку на CPU больше, чем задержки на offload.

Tags: 

Comments

подозреваю, что в том и

подозреваю, что в том и прелесть CUDA, что не нужно придумывать велосипед, а можно взять "известный алгоритм" и получить все прелести его работы.

А если взять более мощную

А если взять более мощную видеокарту и компьютер, тогда задержки станут на порядок меньше? Если станут, то тогда вполне можно будет до 20Гигабит обрабатывать трафика на "домашней" системе. Или я чего-то не понимаю?

Ну с учетом того, что (уже

Ну с учетом того, что (уже после написания этой заметки) в CUDA появилась асинхронная передача данных - смысл возможно уже и появился.

Упретесь со временем в PCIe - и сетевые карты на ней сидят и видеоадаптер, но 20 гигабит наверное можно.

Так если можно анализировать

Так если можно анализировать и фильтровать (используя snort) трафик до 20Гигабит, и если учесть стоимость этого компьютера (до 40-50кр), то это будет являться невероятно классным решением для многих ISP. ИМХО Эх, найти бы единомышленника и протестить...

Не вздумай пробывать, я не

Не вздумай пробывать, я не хочу лагов у себя дома из-за непроверенной системы фильтрации трафика! И так хватает!

ClamAV и Cuda

Наткнулся на статью от тех же ребят (только состав поменьше):
http://www.ics.forth.gr/dcs/Activities/papers/gravity-raid10.pdf

В статье они описывают как реализовали пре-фильтр сигнатур для ClamAV на GPU.
После прочтения у меня появилась куча вопросов к их коду и экспериментам.
Вначале статьи они рапортуют о 100 кратном ускорении;
В fig.7 у них есть ClamAV (8x cores) - что это за 8 cores, может они имели ввиду 8-HT потоков на Xeon E5520(кстати, интересный у них проц - "with 8192KB of L2-cache")?;
100 кратное ускорение у них по сравнению с одним core?
В том же fig.7 у GrAVity около 20Gbit/sec, хотя на fig.5(b) у них около 40Gbit/sec - почему не использовали эти 40 на fig.7?

Их понимание текстурной памяти мне не совсем понятно:
"The texture memory can be accessed in a random fashion for reading, in contrast to global memory, where the access patterns must be coalesced. This feature can be very useful for algorithms like DFA matching, which exhibit irregular access patterns across large data sets. Furthermore, texture fetches are cached, increasing the performance when read operations preserve locality."
Тут вроде у них ошибка с пониманием, из-за чего они перепутали голову лошади с хвостом.
Далее:
"As we will see in Section 4.2, the usage of texture memory can boost the computational throughput up to a factor of two."
Интересно, они вообще не старались делать coalesced?

Пытались ли они как-то забивать shared часто-использующемся данными(например хотя-бы первый state автомата, анализируемые данные и т.п.)? То что они знают о существовании shared ясно из 2.1 (этот абзац такой же как и в статье о gnort). Но факт того, что они не указали это в "3.3 Optimized Memory Management", где кстати с гордостью описали свой approach - "Our approach for hiding memory latencies is to run many threads in parallel.", так же в 3.4. описали ещё одну свою оптимизацию - pinned memory, но при всём при этом ни сказали об использовании shared памяти, что ставит под сомнение использование shared памяти ими (когда по моему мнению использование shared должно дать преимущество на этом алгоритме - во-первых поможет добиться coalesced(хотя может с кэшем и не обязательно), во-вторых поможет хранить повторно используемые данные).

Они использовали gtx295, но походу только наполовину - "Finally we plan on utilizing multiple GPUs instead of a single one."

То что они получили ускорение это безусловно хорошо. Но по-факту они модифицировали изначальный алгоритм, соответственно интересно посмотреть на результаты с использованием оптимизированного CPU пре-фильтра.

И напоследок, эти товарищи решили замерить пиковую производительность своей реализации и получили 110 Gbits/s или 12.8GiB/s : "In this best-case scenario, our throughput reached an order of 110 Gbits/s" (конечно там написано "порядка", но сути не меняет, так как более 100GBit/s). Я никогда получал скорость передачи на GPU близкую к этой, а вы? Неужели они не учитывали передачу данных на GPU? Или может они не учитывали только для этого теста, но тогда почему так мало(или может они получили больше чем написали, ведь "порядка")?
Может их код вообще не работает? В статье они сказали что проверяли "/usr/bin/" - "The files do not contain any virus, however they exercise most code branches of GrAVity". Может конечно они и на вирусах проверяли, но такого описания я в статье не заметил ...

Про 110 там явно написано

Про 110 там явно написано вначале "special case when data is cached on graphics card", т.е. это точно без передачи.

Сценарий понятный: загружаем гигабайт(-другой) данных и фигачим разными паттернами.

Про 110 там явно написано

Про 110 там явно написано вначале "special case when data is cached on graphics card", т.е. это точно без передачи

Спасибо, увидел.
Тогда в этом случае очень мало - The automaton will remain always at the same state, which will be cached., - во всех потоках обрабатывается только одно состояние, и как они пишут оно cached, то есть из глобальной памяти служебные данные (state machine) передаются только один раз(в смысле как должно быть), и в малом объёме - 1024 байта (я думаю на блок). Основная нагрузка на память в этом случае это передача данных которые нужно сканировать - по-идеи каждый байт данных из global в shared должен идти один раз + небольшие "нахлёсты" по краям между соседними блоками данных, то есть даже в самом худшем случае грубо говоря каждый байт из global будет считываться два раза..
То есть при нормальной реализации должно быть намного больше 110GBit/s - по крайней мере я не вижу подводных камней.

Я погуглил быстро на тему

Я погуглил быстро на тему boyer-moore cuda.

Там как-то не видать много-сто-гигабитных скоростей. Скорее - десятки.

От (длины) паттернов зависит, конечно. Разбираться какие именно паттерны в антивирусах, а какие - в тех тестах что на вебе - скучно в столь прекрасный воскресный день.

Там как-то не видать

Там как-то не видать много-сто-гигабитных скоростей. Скорее - десятки.

Так везде наверное пишут с учётом передачи данных на/с gpu, с реальными данными.
Я не спорю с тем, что реальные реализации на реальных данных могут выдавать меньше 100GBit/s.
Меня конкретно смущает их цифра 110GBit/s, при том что используется только одно состояние автомата - это говорит скорей всего об не оптимальной реализации..

Насчёт coalesced я

Насчёт coalesced я погорячился - там не во всех частях получается coalesced.
Кстати, для этой задачи может быть и так, что устройства compute capability 1.3 будут быстрее устройств compute capability 2.x, за счёт того что запрос к памяти идёт от полу-варпа, а не от варпа (например GTX 285 vs GTX 580).