Jump to content
Калькуляторы

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

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/

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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

Share this post


Link to post
Share on other sites

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

Share this post


Link to post
Share on other sites
Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.
Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи.

 

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

 

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

Mikler

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

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

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

Share this post


Link to post
Share on other sites
Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.
Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи.

 

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

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

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

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

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

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

 

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

 

PS:

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

Edited by Mikler

Share this post


Link to post
Share on other sites

По этому поводу хорошо написал 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

 

Share this post


Link to post
Share on other sites
Вы не умничайте :)

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 by zurz

Share this post


Link to post
Share on other sites
Вы не умничайте :)

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

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

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

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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
У более-менее нормальной сетевой карты нет кольцевого буфера в обычном понимании.
не путайте людей.

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Особенно если учесть, что Intel зарезал Larrabee.
Там технология слишком амбициозная и не похожая на то что интел делал до этого.

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
массы поймут что разницы между 2-4--32 ядрами нет
Не беспокойтесь, программисты это исправят :)

 

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this