Yappa Опубликовано 24 августа, 2010 · Жалоба 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/ Может кто-нибудь знает похожие\аналогичные проекты, которые уже можно потрогать? Интересно аж жуть ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 24 августа, 2010 · Жалоба Интересная затея :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 24 августа, 2010 · Жалоба Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая. Но сдается мне что здесь перекладывает CPU. Да есть некоторый эффект но производительность в разы не возрастет, а лишний черный ящик на пути пакета не добавляет надежности :) Если коллеги просветят меня по поводу DMA на X86 буду очень рад :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ThreeDHead Опубликовано 24 августа, 2010 · Жалоба Mikler - Я так думаю что это некоторая вариация RPS, который обсуждаем тут. И обработка там идет тоже наверное на L3. Не даром производительность там на IPv6 более показательна, чем на на IPv4. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 24 августа, 2010 · Жалоба Занимался этим год назад. Могу сказать, что у gpgpu столько внутренних проблем, что не стоит ждать в ближайшее время взрослой технологии, а не экспериментальных студенческих разработок. Особенно если учесть, что Intel зарезал Larrabee. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 24 августа, 2010 · Жалоба У марвела есть такие вкусные чипы с 10G интерфейсами зачем изобретать велосипед... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 24 августа, 2010 · Жалоба Вкусные чипы не умеют нифига делать. И чтобы эти чипы заново чему-то обучить - нужно их целиком менять. А в GPU достаточно другой шейдер залить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 24 августа, 2010 · Жалоба НУ не знаю я всегда думал что залил firmware и API управляй трафиком и очередями разбора. Они конечно горячие тоже, но им далеко до GPU. Вкусный чип это SoC на борту которого CPU + 4x 10G свичь + 1G интерфейсы например. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alex_001 Опубликовано 24 августа, 2010 · Жалоба Вот только нет "download" там - я так понимаю на поиграться эту штуку не заполучить.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LiuPing Опубликовано 24 августа, 2010 · Жалоба Давно ждал когда же кто-нибудь видео GPU приспособит для сетевых дел. ИМХО недооцененная область - массовость, доступность, дешевизна, динамичное развитие. Ведь пытаются же делать на видеокартах суперЭВМ для расчетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 24 августа, 2010 · Жалоба НУ не знаю я всегда думал что залил firmware и API управляй трафиком и очередями разбора. Они конечно горячие тоже, но им далеко до GPU. Вкусный чип это SoC на борту которого CPU + 4x 10G свичь + 1G интерфейсы например. Это все в теории, на самом деле как только кончается голый L3 форвардинг по вшитой табличке, начинаются безумные ценники. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 24 августа, 2010 · Жалоба Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи. Почитайте, в статье написано где "узкое место". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 24 августа, 2010 · Жалоба пусть делают. Через некоторое время это может быть наконец-то собьёт цену на NPU типа того же октеона. А на октеонах софтроутеры уже давно есть, и дают практически wirespeed. голый L3 форвардинг по вшитой табличкевсё зависит от размера этой таблички. как только она не влезает в сам SoC - SoC автоматически превращается в NPU с внешней памятью, а написание софта для многоядерного NPU с конкуррентно лазающим в память кодом это жопа.Такое осилили только циски и 6wind (у которого код купили все остальные). потому и ценник. Mikler вот вам ещё один вкусный чип http://www.vitesse.com/products/product.php?number=VSC7460 вот только та же беда - L3/routing нужно дописывать ручками, либо аутсорсить у той же 6wind, при этом оно будет грузить проц и ни о каком wirespeed мечтать не приходится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 25 августа, 2010 (изменено) · Жалоба Затея интересная узкое место как пакеты с сетевого интерфейса попадают на GPU. Если бы DMA это делала то производительность была бы хорошая.Железок без DMA уже давным-давно не делают - все умеют ходить в основную память и управляются через MMIO. Чуть меньше, но всё еще много, умеют scatter-gather и interrupt-moderation. DMA контроллер времен 386 уже давным-давно не актуален. В современных системах есть I/OAT DMA, но у него несколько другие задачи. Почитайте, в статье написано где "узкое место". Вы не умничайте :) 1. Кто читает пакет из кольцевого буфера сетевой карты? 2. Каким образом он попадает в GPU? 3. Как пакеты из GPU попадают опять же на отправку? Мне не совсем понятна модель в обход CPU. Если объясните буду признателен. Пока я так понял что пришел пакет карта выставила прерывание, дальше процессор считал в SKB и положил его в разделяемую память далее подключается GPU. Объясните уже мне как там по правде :) PS: Сиско системс тоже покупает решения для чипов :) Изменено 25 августа, 2010 пользователем Mikler Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 25 августа, 2010 · Жалоба По этому поводу хорошо написал David Miller из списка рассылки netdev: It's an interesting paper, but we're going to have 64-cpu and 128-cpux86 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 25 августа, 2010 (изменено) · Жалоба Вы не умничайте :)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 толстая шина памяти дала выигрыш по скорости. Изменено 25 августа, 2010 пользователем zurz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 25 августа, 2010 · Жалоба Вы не умничайте :)1. Кто читает пакет из кольцевого буфера сетевой карты? 2. Каким образом он попадает в GPU? 3. Как пакеты из GPU попадают опять же на отправку? Мне не совсем понятна модель в обход CPU. Если объясните буду признателен. У более-менее нормальной сетевой карты нет кольцевого буфера в обычном понимании. В кольцевом буфере хранится не память, а дескрипторы (именно количесво дескрипторов понимается в ethtool -gG). В дескприпторе обозначен, кроме всего прочего, физический адрес и размер этого буфера - именно туда, прямо в оперативную память по физическому адресу сетевая карта на ходу складывает данные принятых пакетов. Кроме этого, один пакет можно собрать и/или разобрать из нескольких буферов (scatter-gather), если нет sg - прийдется принимать в один буфер, а потом копированием делить/собирать. Аналогично и с GPU. В кольцевом буфере не текстуры с шейдерами, а команды с физическими адресами в памяти, где что лежит. Понятно, что задача CPU - выделить память, сказать сетевой карте куда сложить данные, сказать GPU откуда их забрать, и, соответственно, наоборот. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 25 августа, 2010 · Жалоба У более-менее нормальной сетевой карты нет кольцевого буфера в обычном понимании.не путайте людей.имхо вы плаваете в понятиях что такое PCI BAR и что с ними делают. и где собственно физическое адресное пространство, а где локальная память. К примеру, локальная память видеокарты (1Гб) целиком никак не присутствует в карте памяти физических адресов, которыми оперирует CPU. Выделить BAR > 256Mb это вообще моветон, винда например при этом упадёт в BSOD. =) да оно и не нужно нигде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 25 августа, 2010 · Жалоба К примеру, локальная память видеокарты (1Гб) целиком никак не присутствует в карте памяти физических адресов, которыми оперирует CPU. Да, оно не нужно. NIC складывает данные в CPU-memory (не GPU), GPU забирает данные из CPU-memory, в обоих случаях работает bus-mastering, а не CPU копированием из/в BAR. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 26 августа, 2010 · Жалоба X86 архитекторы + маркетологи = простые понятия спрячим за красивыми терминами :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 27 августа, 2010 · Жалоба Щас придумают как видюхами вылавливать торренты и всякую хрень на L7 задёшего :) Особенно если учесть, что Intel зарезал Larrabee.Там технология слишком амбициозная и не похожая на то что интел делал до этого.Скорее всего они увязли в нескольких принципиальных тех проблемах, когда уже почти всё было сделано. Может ещё сделают. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zurz Опубликовано 28 августа, 2010 · Жалоба Larrabee нужна была для написания кода под неё, отладки и профайлинга на типовых задачах, активно жующих память с огромным процентом cache-miss'ов: FFT с огромным окном (1М), свертка сигналов огромной длины (convolution filtering), обработка транзакций БД на сложных неповторяющихся запросах. Желающим Larrabee сейчас доступен под названием Knights Corner, но по факту это мёртвое железо. Операции копирования из памяти в локальную набортную память Larrabee занимают слишком много времени, неудобны для программиста, поэтому (телепат-mode on) в следующей реинкарнации Larrabee будет иметь QPI вместо PCI-E. Со всеми вытекающими. (телепат-mode off) Intel делает решение не для геймеров, а для Hi-End сегмента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 1 сентября, 2010 · Жалоба Оно всё равно попадёт в простые ПК, если не говно. А интелу скоро придётся искать что бы ещё продать - как только массы поймут что разницы между 2-4--32 ядрами нет, и что 2-4 работают даже быстрее, а 4-6-8---32 больше между собой дерутся. Гигагерцы у них уже закончились. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 3 сентября, 2010 · Жалоба массы поймут что разницы между 2-4--32 ядрами нетНе беспокойтесь, программисты это исправят :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 сентября, 2010 · Жалоба Куда там исправлять? На кеш-когерентной архитектуре все числомолотилки вынуждены гонять кеш между собой. Хоть обвешайся ядрами - память,кеш и их синхронизация - будут узкими местами. Быстрый роутинг и ACL-инг (на примитивные рулесы) решается CAM/TCAM-ом. Первый кто сделает сетевку с нужным фичсетом - уделает конкурентов. Подвижки в этом плане есть: http://kerneltrap.org/mailarchive/linux-ne...010/2/4/6268321 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...