[htol 0]

Приветсвую!

 

Нужен высокопроизвоительный гигабит интерфейс (точнее 2), способный принимать/передавать 1Mpps (1 миллион пакетов в секунду) full duplex и не умират при этом от прерываний, а за одно не убивать процессор :crying: . Физика не имеет значения, но в идеале была бы совмещенной медь/sfp.

 

Хочется сделать высокопроизводительный анализатор/генератор трафика с возможностью этого самого трафика изменять на лету (например изменять поля с приоритетами, менять MAC, или работать в качестве транслятора адресов,т.е. изменять входящий адрес адрес при прохождении пакета через устройства на другой и обратно NAT). Обычные писюки умирают от прерываний при таком большой количестве пакетов и в итоге большенство теряется. Флюков на каждый узел тоже не напасешься, да и удаленно они не рулятся. Грубо говоря в итоге хочется получить маршрутизатор с сильно заточенными/обрезанными функциями.

 

Исходя из того что это будет недо маршрутизатор пытаюсь выбрать архитектура для него. Если класическую схему при которой прерываниями контроллера и обработкой принятых пакетов занимается один и тотже процессор, то скорее всего получу такие же проблемы как с PC. Исходя из этого думаю разделить функции приема/передачи, обработки пакетов и управления устройсва разными процессорами. Один из вариантов сделать специализированную плату под эту задачу для высокоскоростной шины например PCI Express, которую воткнуть в PC для управления ею. Плата на борту будет иметь свой гигабитный интерфейс PHY+MAC, процессор для обработки и большая быстрая память. А с помощью PC будет осуществляться инициализация и конфигурирование, снятие статистики для анализа и подготовка правил для изменения или генерации пакетов.

 

Меня интересуют в первую очередь существующие PHY+MAC которые без проблем переварят поток до 1Mpps full duplex. Микропроцессоры заточенные под такого рода задачи. Возможно есть готовые IP процессоры? Тестовые платы на которых можно собрать нечто подобное без больших затрат на самостоятельную разработку. Методы высокоскоростной обработки большого потока информации. Архитектуры такого рода устройств. Ключевые слова для грамотного поиска по данной теме (искал, но так и ненашел ничего похожего, либо 100Мбит/с интерфейс со всеми вытекающими ограничениями либо все наглухо закрыто без публичной информации :twak: ). А так же ссылки на тематические форумы и сайты. Возможно есть похожий open source проект? С удовольствием бы к нему присоединился.

 

Вобщем сильно буду рад любого рода информации и мнений по этому вопросу. :beer:

[xyzzy 0]

Ну, коль уж 1Гбит захотелось, то это что-то в районе 1.4Мппс при 64-байтных пакетах.

В принципе, любой MAC и PHY соответствующий стандарту вполне способен и принять и отослать все на полной скорости. Во времена 32-bit PCI @ 33MHz достьчь полной пропускной способности было затруднительно, но в наши дни PCI-Ex и достаточно шустрые процы ситуацию существенно улучшили.

 

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

 

Если же вам надо все непрерывным потоком, да еще с меняющимися данными, то без FPGA тут, пожалуй, тяжко будет. Скажем, есть у нас 2ГГц проц. При 1Мппс у нас есть примерно 2000 циклов на прием и передачу одного пакета. Кажется - не так-то и мало. Но. Работать мы будем с большим количеством данных, которое в кэш точно не влазит, значит вероятность того, что процессору придется лезть в память довольно велика. Типичное время доступа к памяти - в районе 50-100нс. Существенная часть вашего бюджета уйдет на простой в ожидании памяти, но, в принципе, что-нибудь не сильно сложное сделать возможно. Если вам производительность при малых пакетах не критична, то в принципе, можно и нетривиальные вещи делать.

 

Из вариантов MAC неплохо себя зарекомендовали интеловские 8254* и Broadcom BCM5706/BCM5708.

Оба позволяют откладывать прерывания, чтоб не дергать проц на каждый пакет. Оба с адекватным scatter/gather DMA и позволяют выполнять кое-какие операции полезные в сетевых стеках, но вам, это, наверное, поможет не сильно.

 

Броадкомовские маки особенно интересны, что у них "на борту" у МАКа есть пара собственных процессоров, которые-то уже и занимаются раскладыванием принятых пакетов в память процессору. Несколько лет назад народ из FreeBSD сделал zero-copy прием пакетов.

http://people.freebsd.org/~ken/zero_copy/

 

Однако, в обоих случаях - проблема найти документацию. Что интел, что броадком страдают изрядным геморроем в этом плане.

[htol 0]

Ну, коль уж 1Гбит захотелось, то это что-то в районе 1.4Мппс при 64-байтных пакетах.

В принципе, любой MAC и PHY соответствующий стандарту вполне способен и принять и отослать все на полной скорости.

Т.е. с точки зрения самого интерфейса практически любой удовлетворяет требованием и основная сложность в обеспечении нужной пропускной способности именно в обработке/генерации?

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

Думаю да. Вычисления для такого рода передач не сильно много: crc для ip пакета, для ethernet кадра, я так понимаю это будет делать MAC. Хэш по адресу, и поиск в таблице состояний по этому хэшу. Больше пока вычислений не вижу. Все остальное тупая передача дескрипторов.

Если же вам надо все непрерывным потоком, да еще с меняющимися данными, то без FPGA тут, пожалуй, тяжко будет. Скажем, есть у нас 2ГГц проц. При 1Мппс у нас есть примерно 2000 циклов на прием и передачу одного пакета. Кажется - не так-то и мало. Но. Работать мы будем с большим количеством данных, которое в кэш точно не влазит, значит вероятность того, что процессору придется лезть в память довольно велика. Типичное время доступа к памяти - в районе 50-100нс. Существенная часть вашего бюджета уйдет на простой в ожидании памяти, но, в принципе, что-нибудь не сильно сложное сделать возможно. Если вам производительность при малых пакетах не критична, то в принципе, можно и нетривиальные вещи делать.

А вот здесь, если можно, поподробнее. Чем мне поможет fpga, если все равно нужно будет обращаться к памяти? Я так понимаю что скорость доступа к DDR ниже? Например ddr 333MHz 32 bit получаем что-то типа 1s/(333MHz*32bit)= 0.7 нс даже если попадется плохой кусок то задержка будет максимум 15 тактов. Т.е. получается на 2 порядка меньше ваших цифр? Хотя я не исключаю что у меня плохо с арифметикой в 4 часа ночи :) . Хотя я изначально думал что без fpga вообще ничего не сделаешь при приеме/передачи + какой-нить обработки пакетов без того чтоб не задушить процессор прерываниями.

Из вариантов MAC неплохо себя зарекомендовали интеловские 8254* и Broadcom BCM5706/BCM5708.

Оба позволяют откладывать прерывания, чтоб не дергать проц на каждый пакет. Оба с адекватным scatter/gather DMA и позволяют выполнять кое-какие операции полезные в сетевых стеках, но вам, это, наверное, поможет не сильно.

Помоему для меня это не реальные варианты :( . Я на это дело так и не смог найти даташитов, когда правил драйвера к сетевухам броадкомовским для фриибсд. Думаю что с интелом будет тоже самое.

Броадкомовские маки особенно интересны, что у них "на борту" у МАКа есть пара собственных процессоров, которые-то уже и занимаются раскладыванием принятых пакетов в память процессору. Несколько лет назад народ из FreeBSD сделал zero-copy прием пакетов.

http://people.freebsd.org/~ken/zero_copy/

 

Однако, в обоих случаях - проблема найти документацию. Что интел, что броадком страдают изрядным геморроем в этом плане.

Вот-вот.

[xyzzy 0]

Вычисления для такого рода передач не сильно много: crc для ip пакета, для ethernet кадра, я так понимаю это будет делать MAC. Хэш по адресу, и поиск в таблице состояний по этому хэшу. Больше пока вычислений не вижу.

 

Тут есть где фантазии разыграться. :-) Взгляните на серьезные генераторы (а заодно и анализаторы) траффика типа Ixia, SmartBits или Agilent. Там можно сотворить практически все, что угодно. Из тривиального и наиболее полезного, к примеру - можно заставить отсылать пакеты на кучу разных VLAN, с уникальным Dest IP, в каждый пакет запихивать timestamp, чтобы потом можно было измерить время путешествия. По отдельности - немного, но в сумме на скоростях больше гигабита нагрузка выходит изрядная. Если готовить все это в памяти, то ее просто не хватит надолго. Скажем, при гигабите надо 100Мб/с. 1Гб - 10 секунд. Не особо густо, если надо гонять траффик целый день.

 

Чем мне поможет fpga, если все равно нужно будет обращаться к памяти?

 

В том-то и фокус, что с FPGA можно и без внешней памяти. Формируешь пакеты на лету как тебе надо и скармливаешь синтезированому MACу напрямую. Формирование пакетов - тоже не сильно сложно реализуется - всего-то надо кучку примитивных генераторов по одному на поле в пакете (SRC MAC, DST MAC, Src IP, Dst IP, и т.д.) плюс кучу MUX'ов и FIFO, чтобы из отдельных полей сшить пакет. Генераторы - инкремент.декремент с шагом и/или последовательно вытаскивать данные из таблицы.

 

Я так понимаю что скорость доступа к DDR ниже? Например ddr 333MHz 32 bit получаем что-то типа 1s/(333MHz*32bit)= 0.7 нс даже если попадется плохой кусок то задержка будет максимум 15 тактов.

 

С пропускной способностью у памяти действительно все относительно неплохо. Вот только задержка доступа по прежнему хромает. Вот тут довольно неплохо все проиллюстрировано: http://www.digit-life.com/articles2/ddr2-rmma/ddr2-rmma.html

 

Реально даже на процессорах со встроенным контроллером памяти меньше 50нс получить сложно. AMD в этом смысле существенно лучше. Интел пока что изрядно отстает, ибо ему приходится через мост в память лезть.

 

А может вам какой-нибудь Virtex4Pro подойдет. У него на борту и гигабитный мак есть и PowerPC проц.

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