Jump to content

    

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

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

 

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

 

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

 

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

 

Удачи! Rob.

 

Share this post


Link to post
Share on other sites
Приветствую!

 

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

 

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

 

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

 

Удачи! Rob.

Ну надо же!

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

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

Share this post


Link to post
Share on other sites

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

...

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

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

 

Удачи! Rob.

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

4 minutes ago, TRILLER said:

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

...

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

Удачи! Rob.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites
1 hour ago, RobFPGA said:

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

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

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

Share this post


Link to post
Share on other sites
19 минут назад, fguy сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

27 minutes ago, fguy said:

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

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

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

 

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
1 hour ago, Flood said:

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

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

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

Share this post


Link to post
Share on other sites

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

9 minutes ago, fguy said:

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

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

Удачи! Rob.

Share this post


Link to post
Share on other sites
1 hour ago, RobFPGA said:

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

 

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

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

Share this post


Link to post
Share on other sites

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

3 minutes ago, fguy said:

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

...

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

Успехов! Rob.

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