Самый быстрый и самый маленький TCP-стек., По просьбам трудящихся. Опции

[Rst7]

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

 NikeE_CM3.zip ( 350.37 килобайт ) Кол-во скачиваний: 563


Собирается IAR'ом 6.20.3 (вроде крайний на текущий момент), за подправить для GCC - даже не просите.

В качестве PHY используется KSZ8041TL, что, в общем, не принципиально - править, если что, файл emac.c

Тактовая проца в проекте - 100МГц, кварц - 20МГц, менять - функция InitPLL в файле hardware_init.c

Так же для генерации 50МГц REFCLK используется сам процессор через модуль CLKOUT. Кому не надо, в файле hardware_init.c необходимо убрать

CODE

  //Нужно если 50МГц для RMII генерируется процом
  PINSEL3 |= (0x01UL<<22); //CLKOUT on P1.27
  CLKOUTCFG=0x00000110; //CLKOUT 100MHz/2=50MHz used for RMII

Стек поддерживает TCP (и серверные, и клиентские сокеты), ICMP. Очень не долго прикрутить UDP. Поддерживается Fast Retransmit на передачу. На прием - сделаю чуть позже (если, конечно, понадобится).

Архитектура стека - callback по событиям из низкоприоритетного прерывания (используется модуль RIT как таймер, необходимый для TCP и заодно происходит Wakeup этого потока при поступлении пакетов - через прерывание от EMAC, которые должно быть высокоприоритетным (но при этом очень короткое, TODO - управление Flow Control)). Сам стек - network.c.

По умолчанию IP-адрес - 192.168.0.100.

Есть вебинтерфейс, даже с поддержкой ajax - можно поставить галочку Update Graphics и повеселиться (естественно, с браузером, который понимает HTML5 - Опера, Хром, Тормозилла - все годится). Кнопки "<<" и ">>" тоже можно понажимать. Для создания и отображения этих данных копать show_data.c и HTMLsource/http_root_level3.

Еще там случайно md5-авторизация в вебсервере сделана



Эмулятор EEPROM в проекте не прикручен, так что на страничке конфигурации настройки стека не сохраняются. Когда у себя в проекте прикручу, сюда сделаю порт.

На порту 2000 висит отдаватель файла со случайными числами размером 100 мегабайт - это для теста скорости. В папочке GetData лежит проект забирателя для большого брата (собирать C++ Builder'ом).

Ну вот теперь, собственно, за скорость. По TCP - 90Мбит/с.


На этом, кстати, предлагаю закончить спор о максимально достижимой скорости по TCP.

Ну размеры вообще не угадываются - 3.7кБ собственно стек, вебсервер - 3.5кБ. Ах да, там еще странички пакуются, но это осталось с версии для AVR, можно честно выбросить.

Собственно, примеры использования можно смотреть в rx_tcp_dump.c (тупой отправлятель данных) и http_server.c (веб-сервер, там берегите мозг).

Ну и на посошок - лицензии. От это все - GPL, так что пользуйтесь.

На все вопросы постараюсь ответить тут.

Добавлено 29 июня 2011г:
http://electronix.ru/forum/index.php?s=&am...st&p=956930 - ревизия 1315.

Добавлено 30 июля 2011г:
http://electronix.ru/forum/index.php?s=&am...st&p=957213 - ревизия 1318.

[Rst7]

Угу, а если стек занят (ну по другому сокету что-то отдает или удаленный хост задумался, пакет пропал и тд) и этот wakeup задерживается? Причем в общем случае он так нехило на секунды задержаться может. При этом ресурс MMC+SPI заблокирован и никто им больше пользоваться в этот момент не может (ну там логгер чего писнуть хочет).

Почему? Задержка будет максимум на время приготовления или обработки пакета. Конечно, надо всегда минимизировать время обработки данных.

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

И тут всегда можно вычислить. А иногда - например, для разбора HTTP-запросов, оно и нафиг не нужно, все делается на лету.

В общем, при такой архитектуре принципиально иным должно быть построение остального кода. Только тогда будут скорости. Хотя, в общем-то и в обычных bsd-style дизайнах нельзя забывать о том, что, например, очень нежелательно кормить, скажем, функцию send по одному байту. Понятное дело, что есть буферизация, но накладные расходы на вызов будут просто феерические.

А с другой стороны сама по себе bsd-style архитектура не позволяет работать с zero-copy. А zero-copy - это не только в самом стеке, но и еще и в генераторе/приемнике данных. Т.е. проблему скорости надо решать в комплексе.

А Вы тестировали точка-точка?

Свич торчит 16типортовый между девайсом и большим братом.

Можно, используя RTOS и вместо колбеков флаги. Относительно легко переделывается.

Там все-же сложнее ситуация. И опять-же, повторюсь, решать ее надо в комплексе. Обработчик медленный и печальный - уносите его в низкоприоритетную задачу/прерывание (я просто разноприоритетными прерываниями как неким аналогом RTOS пользуюсь), разбивайте его на подзадачи, возможно - добавляйте ему необходимые буфера.