высокопроизводительный gigabit, помогите определиться с базой и возможной архитектурой Опции

[htol]

Приветсвую!

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

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

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

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

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

[xyzzy]

Ну, коль уж 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]

Ну, коль уж 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/

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

Вот-вот.