Перейти к содержанию

    

Низкоуровневая верификация TCP/IP стека в FPGA

Приветствую!

 

Собственно subj. Озадачили меня вот. :cranky:

 

Есть некая реализация TCP/IP покрытая неким подобием функциональных тестов. И надо бы проверить на соответствие всяким RFC. Понятное дело можно учитаться спецификациями вусмерть (и кажется мне этого не избежать). Но может есть что для более легкого старта - типа набора скриптов/сценариев покрывающих основные требования. Или библиотеки какие для генерации пакетов по таким сценариям. Чтобы можно было их например прикрутить их через DPI к симулятору.

 

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

 

Удачи! Rob.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Приветствую!

 

Собственно subj. Озадачили меня вот. :cranky:

 

Есть некая реализация TCP/IP покрытая неким подобием функциональных тестов. И надо бы проверить на соответствие всяким RFC. Понятное дело можно учитаться спецификациями вусмерть (и кажется мне этого не избежать). Но может есть что для более легкого старта - типа набора скриптов/сценариев покрывающих основные требования. Или библиотеки какие для генерации пакетов по таким сценариям. Чтобы можно было их например прикрутить их через DPI к симулятору.

 

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

 

Удачи! Rob.

Ну надо же!

Прошу прощения за грубость. :)

Случайно не Бостон?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

...

Случайно не Бостон?

Нее - так далеко от родного дома я еще на уехал :)

 

Удачи! Rob.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может лучше купить? 

https://www.xilinx.com/products/intellectual-property/1-6ogk1b.html#overview

Если кто-нибудь уже пользовал, было бы неплохо услышать мнение..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

4 minutes ago, TRILLER said:

Может лучше купить? 

...

Зачем же покупать то что уже есть?  Вот того чего нет я бы прикупил если не дорого :) 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

у xilinx на гите есть исходники парсера тср под 10гбит на хлс https://github.com/Xilinx/HLx_Examples/tree/master/Acceleration/tcp_ip

в них есть и тестбенчи для ядер - может чего там и по теме найдете

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На правах просто идеи: прикрутить через симулятор, тот же DPI, некую обертку, которая будет работать в живой сети через некую прослойку. Ну а тестов для обычного программного TCP/IP навалом должно быть. Единственное что, задержки будут сильно беспокоить, но в остальном на соответствие проверить можно, каждое поле, каждый пакет и так далее. Не смотрите что я фанатик, но в Linux задача заворота сетевого порта в симулятор решается гораздо проще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

8 hours ago, fguy said:

у xilinx на гите есть исходники парсера тср под 10гбит на хлс https://github.com/Xilinx/HLx_Examples/tree/master/Acceleration/tcp_ip

в них есть и тестбенчи для ядер - может чего там и по теме найдете

С этим чудом я понемногу разбираюсь. Но как мне кажется там тесты просто проверяют основной функционал  в идеальном варианте событий.  

46 minutes ago, AVR said:

На правах просто идеи: прикрутить через симулятор, тот же DPI, некую обертку, которая будет работать в живой сети через некую прослойку. Ну а тестов для обычного программного TCP/IP навалом должно быть. Единственное что, задержки будут сильно беспокоить, но в остальном на соответствие проверить можно, каждое поле, каждый пакет и так далее. Не смотрите что я фанатик, но в Linux задача заворота сетевого порта в симулятор решается гораздо проще.

Это как раз не сложно.  Пока основной вопрос именно в сценариях ситуаций в которых надо бы проверить поведение корки. 

Успехов! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, RobFPGA said:

С этим чудом я понемногу разбираюсь. Но как мне кажется там тесты просто проверяют основной функционал  в идеальном варианте событий.  

А какой смысл копать глубже - если только авторы вашего ядра ТСР не хотят получить красивый сертификат в рамочке, который ни о чем.

По факту в плис отправка или прием данных в виде TCP/IP/UDP пакетов делается небольшим ядрышком в паре со штатным IP нужного эзернета, а критерием работоспособности служит правильная работа, а не сертификат в рамочке, да и реализация всех фишек протоколов и "защита от дурака" чаще всего не нужна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
19 минут назад, fguy сказал:

А какой смысл копать глубже - если только авторы вашего ядра ТСР не хотят получить красивый сертификат в рамочке, который ни о чем.

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

Я вот совсем не понимаю, как можно достаточно хорошо оттестировать TCP, чтобы он гарантированно не заглючил через год-другой в малоповторимой ситуации. Протокол все-таки не очень простой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

27 minutes ago, fguy said:

А какой смысл копать глубже - если только авторы вашего ядра ТСР не хотят получить красивый сертификат в рамочке, который ни о чем.

По факту в плис отправка или прием данных в виде TCP/IP/UDP пакетов делается небольшим ядрышком в паре со штатным IP нужного эзернета, а критерием работоспособности служит правильная работа, а не сертификат в рамочке, да и реализация всех фишек протоколов и "защита от дурака" чаще всего не нужна.

Ну я частично тоже автор этой корки и от красивого сертификата не отказалcя бы ;)  Который хоть и ни чем но иногда очень даже помогает ;)

 

А критерий правильной работы понятие расплывчатое. Современный зоопарк сетевых решений  это тот еще геморрой. И когда стоит задача не просто что-то и как-то передать  а и гарантировать работу в разном окружении то приходится  с этим зоопарком считаться. А то на тестовом стенде все работает пучком - а как заказчику поставишь  начинается - "... Ай Ай Ай - ваша железка шлет кучу ретрансмитов! Почему? Срррочно исправьте! ..."   И начинаешь  разгребать гигабайты  pcap  файлов чтобы понять что не так и где именно - у меня или у заказчика в sw стеке или конфигурации. И хорошо когда эти pcap доступны, а бывает что и их не дают из за security policy :(. 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, Flood said:

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

Я вот совсем не понимаю, как можно достаточно хорошо оттестировать TCP, чтобы он гарантированно не заглючил через год-другой в малоповторимой ситуации. Протокол все-таки не очень простой.

По своему опыту поднятия обмена по UDP без всяких там лвипов и т.п. могу сказать что чем проще тем надежнее - для того же обмена по UDP достаточно отвечать на ARP и ВСЁ - для пущего понту можно еще на простой пинг отвечать - остальное от лукавого. Генерация мультикаста UDP вообще не требует ни на что отвечать - только правильно формировать пакеты. Не нужно забывать что зачастую на плис в качестве физикалов вешаются многоканальные свитчи которые живут своей жизнью и за их поведение отвечать трудновато.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

9 minutes ago, fguy said:

По своему опыту поднятия обмена по UDP без всяких там лвипов и т.п. могу сказать что чем проще тем надежнее - для того же обмена по UDP достаточно отвечать на ARP и ВСЁ - для пущего понту можно еще на простой пинг отвечать - остальное от лукавого. Генерация мультикаста UDP вообще не требует ни на что отвечать - только правильно формировать пакеты. Не нужно забывать что зачастую на плис в качестве физикалов вешаются многоканальные свитчи которые живут своей жизнью и за их поведение отвечать трудновато.

Понятное дело для UDP вообще все просто тем более если для собственного использования. У меня несколько таких систем работает с потоком 4-8 GByte/s. В ручную статически сконфигурил и льешь в сеть дер.данные, положив на всех большой и толстый 10G ;). Но для удобства все же нужен полный ICMP и DHCP. Либо полностью в железе, либо замыкать соответствующие пакеты через bypass софт стек.  Чтобы вовремя реагировать если заказчик вдруг поменяв конфигурацию сети  не удивлялся что за хренов трафик идет север по старому IP :) 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, RobFPGA said:

У меня несколько таких систем работает с потоком 4-8 GByte/s. В ручную статически сконфигурил и льешь в сеть дер.данные, положив на всех большой и толстый 10G ;).

 

Вы ничего не путаете - 4 Гбайта/с это уже 40 Гбитный эзернет, а не 10?

DHCP вроде никто не просил пока - всем хватает статичных IP и MAC с возможностью оперативной реконфигурации - типа выдаем кучу одинаковых коробочек с одним IP и MAC по серийнику, а заказчик сам выставляет перед вводом в эксплуатацию желаемые адреса, если у него меняется адресная конфигурация сети, то он сам меняет адреса как хочет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую! 

3 minutes ago, fguy said:

Вы ничего не путаете - 4 Гбайта/с это уже 40 Гбитный эзернет, а не 10?

...

Нет не путаю - 4 штуки 10G по UDP льют из FPGA общий поток параллельно. На приемной стороне все собирается опять в один поток.

Успехов! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти