Роутер с игровой видеокартой

[Yappa]

PacketShader is a high-performance PC-based software router platform that accelerates the core packet processing with Graphics Processing Units (GPUs). Based on our observation that the CPU is the typical performance bottleneck in high-speed sofware routers, we scale the computing power in a cost-effective manner with massively-parallel GPU. PacketShader offloads computation and memory-intensive router applications to GPUs while optimizing the packet reception and transmission path on Linux. With extensive batch processing and pipelining, PacketShader achieves an unprecedented IP packet forwarding performance of 40 Gbps on an eight-core Nehalem server even for 64-byte packet size.

http://shader.kaist.edu/packetshader/

 

Может кто-нибудь знает похожие\аналогичные проекты, которые уже можно потрогать? Интересно аж жуть )

[ThreeDHead]

Интересная затея :)

[Mikler]

Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая. Но сдается мне что здесь перекладывает CPU. Да есть некоторый эффект но производительность в разы не возрастет, а лишний черный ящик на пути пакета не добавляет надежности :)

 

Если коллеги просветят меня по поводу DMA на X86 буду очень рад :)

[ThreeDHead]

Mikler - Я так думаю что это некоторая вариация RPS, который обсуждаем тут. И обработка там идет тоже наверное на L3. Не даром производительность там на IPv6 более показательна, чем на на IPv4.

[jab]

 

Занимался этим год назад. Могу сказать, что у gpgpu столько внутренних проблем, что не стоит ждать в ближайшее время взрослой технологии, а не

экспериментальных студенческих разработок. Особенно если учесть, что Intel зарезал Larrabee.

[Mikler]

У марвела есть такие вкусные чипы с 10G интерфейсами зачем изобретать велосипед...

[jab]

Вкусные чипы не умеют нифига делать. И чтобы эти чипы заново чему-то обучить - нужно их целиком менять. А в GPU достаточно другой шейдер залить.

[Mikler]

НУ не знаю я всегда думал что залил firmware и API управляй трафиком и очередями разбора. Они конечно горячие тоже, но им далеко до GPU. Вкусный чип это SoC на борту которого CPU + 4x 10G свичь + 1G интерфейсы например.

[alex_001]

Вот только нет "download" там - я так понимаю на поиграться эту штуку не заполучить..

[LiuPing]

Давно ждал когда же кто-нибудь видео GPU приспособит для сетевых дел. ИМХО недооцененная область - массовость, доступность, дешевизна, динамичное развитие. Ведь пытаются же делать на видеокартах суперЭВМ для расчетов.

[jab]

НУ не знаю я всегда думал что залил firmware и API управляй трафиком и очередями разбора. Они конечно горячие тоже, но им далеко до GPU. Вкусный чип это SoC на борту которого CPU + 4x 10G свичь + 1G интерфейсы например.

Это все в теории, на самом деле как только кончается голый L3 форвардинг по вшитой табличке, начинаются безумные ценники.

[vitalyb]

Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.

Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи.

 

Почитайте, в статье написано где "узкое место".

 

[zurz]

пусть делают. Через некоторое время это может быть наконец-то собьёт цену на NPU типа того же октеона.

А на октеонах софтроутеры уже давно есть, и дают практически wirespeed.

 

голый L3 форвардинг по вшитой табличке

всё зависит от размера этой таблички. как только она не влезает в сам SoC - SoC автоматически превращается в NPU с внешней памятью, а написание софта для многоядерного NPU с конкуррентно лазающим в память кодом это жопа.

Такое осилили только циски и 6wind (у которого код купили все остальные). потому и ценник.

 

Mikler

вот вам ещё один вкусный чип

http://www.vitesse.com/products/product.php?number=VSC7460

вот только та же беда - L3/routing нужно дописывать ручками, либо аутсорсить у той же 6wind, при этом оно будет грузить проц и ни о каком wirespeed мечтать не приходится.

[Mikler]

Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.

Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи.

 

Почитайте, в статье написано где "узкое место".

Вы не умничайте :)

1. Кто читает пакет из кольцевого буфера сетевой карты?

2. Каким образом он попадает в GPU?

3. Как пакеты из GPU попадают опять же на отправку?

Мне не совсем понятна модель в обход CPU. Если объясните буду признателен.

 

Пока я так понял что пришел пакет карта выставила прерывание, дальше процессор считал в SKB и положил его в разделяемую память далее подключается GPU. Объясните уже мне как там по правде :)

 

PS:

Сиско системс тоже покупает решения для чипов :)

Edited August 25, 2010 by Mikler

[Умник]

По этому поводу хорошо написал David Miller из списка рассылки netdev:

It's an interesting paper, but we're going to have 64-cpu and 128-cpu

x86 machines commonly quite soon, so the arity of parallelism these

guys are getting in return (at a cost of generality) will decrease

steadily over time.

http://www.spinics.net/lists/netdev/msg138899.html

 

[zurz]

Вы не умничайте :)

1. Кто читает пакет из кольцевого буфера сетевой карты?

2. Каким образом он попадает в GPU?

3. Как пакеты из GPU попадают опять же на отправку?

Мне не совсем понятна модель в обход CPU. Если объясните буду признателен.

классика на CPU:

1. по заполнению кольцевого буфера карточка по almostfull поднимает прерывание

2. проц по прерыванию мапит память и инициализирует DMA-контроллер сетёвки на передачу буфера в память

3. DMA-контроллер пишет в память, по окончанию опять поднимает прерывание

4. проц видит что DMA-передача закончилась, размапливает память

5. проц проводит класификацию пришедшего куска памяти (на самом деле пачки пакетов): выделаят память, копирует из памяти в память, поднимает флажки в нужных полях

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

7. проц готовит данные к передаче - копирует пакетики в формате, пригодном для скармливания DMA-контроллеру сетевой

8. проц мапит память и инициализирует DMA-контроллер сетёвки на передачу из памяти в кольцевой буфер сетёвки

9. DMA-контроллер пишет в память, по окончанию опять поднимает прерывание

10. проц размапливает память.

 

мужики решили оптимизировать п.5 и п.6 на GPU:

 

начиная с п.5 отличия:

5. проц инициализирует DMA-контроллер видео на передачу из память в локальную память видео

6. DMA-контроллер видеокарточки читает из памяти в свою локальную, по окончанию поднимает прерывание

7. проц видит что DMA-передача закончилась, размапливает память

8. на GPU запускается матчинг по табличке

9. всё вываливается в обратную сторону тем же порядком.

 

откуда профит? в статье написано, что при обработке ethernet пакета размером 64 байта linux kernel выделяет 64+208 байт памяти, что есть оверкилл, и на mmap()+unmap() дофига времени при обработке IP уходит.

В их же модели пакеты процом вообще не обрабатываются, а на GPU толстая шина памяти дала выигрыш по скорости.

Edited August 25, 2010 by zurz

[vitalyb]

Вы не умничайте :)

1. Кто читает пакет из кольцевого буфера сетевой карты?

2. Каким образом он попадает в GPU?

3. Как пакеты из GPU попадают опять же на отправку?

Мне не совсем понятна модель в обход CPU. Если объясните буду признателен.

У более-менее нормальной сетевой карты нет кольцевого буфера в обычном понимании. В кольцевом буфере хранится не память, а дескрипторы (именно количесво дескрипторов понимается в ethtool -gG). В дескприпторе обозначен, кроме всего прочего, физический адрес и размер этого буфера - именно туда, прямо в оперативную память по физическому адресу сетевая карта на ходу складывает данные принятых пакетов. Кроме этого, один пакет можно собрать и/или разобрать из нескольких буферов (scatter-gather), если нет sg - прийдется принимать в один буфер, а потом копированием делить/собирать.

 

Аналогично и с GPU. В кольцевом буфере не текстуры с шейдерами, а команды с физическими адресами в памяти, где что лежит.

 

Понятно, что задача CPU - выделить память, сказать сетевой карте куда сложить данные, сказать GPU откуда их забрать, и, соответственно, наоборот.

 

[zurz]

У более-менее нормальной сетевой карты нет кольцевого буфера в обычном понимании.

не путайте людей.

имхо вы плаваете в понятиях что такое PCI BAR и что с ними делают. и где собственно физическое адресное пространство, а где локальная память.

К примеру, локальная память видеокарты (1Гб) целиком никак не присутствует в карте памяти физических адресов, которыми оперирует CPU. Выделить BAR > 256Mb это вообще моветон, винда например при этом упадёт в BSOD. =) да оно и не нужно нигде.

[vitalyb]

К примеру, локальная память видеокарты (1Гб) целиком никак не присутствует в карте памяти физических адресов, которыми оперирует CPU.

Да, оно не нужно. NIC складывает данные в CPU-memory (не GPU), GPU забирает данные из CPU-memory, в обоих случаях работает bus-mastering, а не CPU копированием из/в BAR.

[Mikler]

X86 архитекторы + маркетологи = простые понятия спрячим за красивыми терминами :)

[Ivan_83]

Щас придумают как видюхами вылавливать торренты и всякую хрень на L7 задёшего :)

 

Особенно если учесть, что Intel зарезал Larrabee.

Там технология слишком амбициозная и не похожая на то что интел делал до этого.

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

Может ещё сделают.

[zurz]

Larrabee нужна была для написания кода под неё, отладки и профайлинга на типовых задачах, активно жующих память с огромным процентом cache-miss'ов: FFT с огромным окном (1М), свертка сигналов огромной длины (convolution filtering), обработка транзакций БД на сложных неповторяющихся запросах.

Желающим Larrabee сейчас доступен под названием Knights Corner, но по факту это мёртвое железо. Операции копирования из памяти в локальную набортную память Larrabee занимают слишком много времени, неудобны для программиста, поэтому (телепат-mode on) в следующей реинкарнации Larrabee будет иметь QPI вместо PCI-E. Со всеми вытекающими. (телепат-mode off)

Intel делает решение не для геймеров, а для Hi-End сегмента.

[Ivan_83]

Оно всё равно попадёт в простые ПК, если не говно.

А интелу скоро придётся искать что бы ещё продать - как только массы поймут что разницы между 2-4--32 ядрами нет, и что 2-4 работают даже быстрее, а 4-6-8---32 больше между собой дерутся.

Гигагерцы у них уже закончились.

[vitalyb]

массы поймут что разницы между 2-4--32 ядрами нет

Не беспокойтесь, программисты это исправят :)

 

[nuclearcat]

Куда там исправлять?

 

На кеш-когерентной архитектуре все числомолотилки вынуждены гонять кеш между собой.

Хоть обвешайся ядрами - память,кеш и их синхронизация - будут узкими местами.

Быстрый роутинг и ACL-инг (на примитивные рулесы) решается CAM/TCAM-ом. Первый кто сделает сетевку с нужным фичсетом - уделает конкурентов.

Подвижки в этом плане есть:

http://kerneltrap.org/mailarchive/linux-ne...010/2/4/6268321