[Rst7 5]

Угу, и еще залезли в s->win и сделали его нулевым, потому как вдруг уйдет ACK с новым ACKNO и удаленный хост вышлет новые данные. Готична.

 

А как еще? Именно так. Только бояться не надо, ничего сложного.

[VslavX 0]

Возможно я не прав, но реализация протокола от Rst7 заточена под вполне конкретное применение. Это позволяет выжать максимум скорости для данной реализации. Отсюда и MAC, и коллбэки, и не совсем четко разнесенная по уровням обработка. Но если устройство соответствует ТЗ, то это абсолютно не важно.

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

 

 

А как еще? Именно так. Только бояться не надо, ничего сложного.

Угу, для Вас несложно, для меня несложно, а для человека, незнакомого с протоколом TCP - вполне себе может быть проблемой.

[Rst7 5]

а для человека, незнакомого с протоколом TCP - вполне себе может быть проблемой.

 

Так надо тогда профессию сменить на грузчика. А нам, профессионалам, денег будет больше.

 

Возможно я не прав, но реализация протокола от Rst7 заточена под вполне конкретное применение. Это позволяет выжать максимум скорости для данной реализации.

 

Именно. Более того, оптимальный стек с ppp-транспортом должен строиться по другим принципам.

 

Более того, все забывают о том, что ресурсов в притык. Если флеша еще хватает с головой, то с ОЗУ - крепкие напряги. А ведь TCP-стек в устройстве - это не конечная цель, а всего лишь некая подсистема для обеспечения работы основного функционала. И она должна быть экономичной по ресурсам.

[blackfin 23]

Более того, все забывают о том, что ресурсов в притык. Если флеша еще хватает с головой, то с ОЗУ - крепкие напряги.

Ага, вот тут и встает наш Главный холиварный Вопрос: "Что делать, - каждый раз заново переписывать кривой уникальный TCP/IP-стек под каждый новомодный нанопроцессор, или доплатить денег, и купить более подходящий по ресурсам микропроцессор, в который без лишних телодвижений влезет нормальный, полнофункциональный, скоростной TCP/IP-стек + RTOS + Ваше_Любимое_Приложение?"

[Rst7 5]

Ага, вот тут и встает наш Главный холиварный Вопрос

 

Да порочный это подход. Если следовать таким рассуждениям, то вообще нельзя использовать EMAC в контроллерах класса рассматриваемого.

[yakub_EZ 0]

IAR 6.21.1.2846 и common components 6.3.3.1990. При компиляции просит revision.c, где его взять?

[Rst7 5]

При компиляции просит revision.c, где его взять?

 

Он при компиляции создается отдельной софтиной. Можно сделать вручную из revision.tmpl, там просто строка текстовая в константу засовывается, т.е. шаблон заменить на 123, например.

 

И еще, собирать надо Target Release.

[zltigo 1]

Ага, вот тут и встает наш Главный холиварный Вопрос: "Что делать, - каждый раз заново переписывать кривой уникальный TCP/IP-стек под каждый новомодный нанопроцессор, или доплатить денег, и купить более подходящий по ресурсам микропроцессор, в который без лишних телодвижений влезет нормальный, полнофункциональный, скоростной TCP/IP-стек + RTOS + Ваше_Любимое_Приложение?"

При этом в этом "нормальный, полнофункциональный, скоростной TCP/IP-стек" не будет MAC уровня под Ваше железо или вообще, либо MAC будет написан минимально-формально. Это вообще-то сразу вычеркивает слово "скоростной" ( по отношению к стеку, а не процессору ). В дополнение к MAC написанному для галочки скорее всего вылезут еще и проблемы минимальности-универсальности-убогости взаимодействия с MAC уровнем вообще. Захочешь реально сделать конкретную работу хорошо по любому придется либо перепахивать нечто чужое и большое, либо, как вариант, что-то более-менее обозримое и заточенное под задачу. Иначе прямой путь не глядя за ради IP стека к чему-либо типа штопанного Линукса и гигагерцам.

[VslavX 0]

Да порочный это подход. Если следовать таким рассуждениям, то вообще нельзя использовать EMAC в контроллерах класса рассматриваемого.

ИМХО, как раз LPC17xx неудачно выбран для иллюстрации уникальности стека. Если на AVR (откуда это все было портировано) с такой уникальностью еще можно было смириться, то на LPC17xx (у которого ресурсов более чем) это вызывает удивление.

 

[blackfin 23]

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

Так я, если Вы заметили, именно за это и голосую обеими руками..

 

А именно, всё железо-зависимое нужно вынести в сетевой драйвер. В этом драйвере и будут жить все железо-зависимые функции MAC уровня, типа SGDMA, IO, MDIO, и пр. (ессно, в зависимости от возможностей процессора). При этом сам TCP/IP-стек должен быть максимально независимым от аппаратной платформы, т.е., "НЕ уникальным" и иметь четко выраженный формализованный интерфейс на основе стандартных вызовов: OpenDevice(), DeviceIOCtl(), SyncRead(), SyncWrite(), CloseDevice(). В этом случае, при переходе на другую платформу, нужно будет переписать только драйвер. TCP/IP-стек, при этом, останется без изменений.

 

Как-то так.. :laughing:

[zltigo 1]

и иметь четко выраженный формализованный интерфейс на основе стандартных вызовов

Примитивность этого формализованного интерфейса обычно и гробит :( возможности MAC железа сводя их к нескольким унылым примитивам. В результате чего приходится править этот самый "независимый" (от разума) стек до получения приемлимого результата за счет правильного использования MAC железа. Или наращивать мегагерцы и ядра для компенсации "унифицированного" подхода к работе.

[VslavX 0]

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

А что там по Вашему должно быть? Очереди входящих и исходящих пакетов, функция руления линком и его параметрами - разрешение/запрет, выбор скорости, MDX, можно еще доступ к регистрам PHY для доступа к его особому функционалу. Ну у меня есть еще колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования. А чего еще от MAC-а нужно-то?

 

[zltigo 1]

А что там по Вашему должно быть?

Там должно быть то, что позволит полностью использовать возможности конкретного железа. Вот у Вас есть то, что Вы назвали "колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования". Вы еще мечтаете об использовании аппаратного CRC. Как это ложится на нечто абстрактно универсальное взаимодействие с MAC уровнем массово низводимое разработчиками "универсальных" стеков в своей основной функции до передать/принять фрейм?

[Rst7 5]

ИМХО, как раз LPC17xx неудачно выбран для иллюстрации уникальности стека.

 

Ну почему же? Вполне такой себе середнячок по нынешним временам. Мейнстрим.

 

то на LPC17xx (у которого ресурсов более чем) это вызывает удивление.

 

Ресурсов более чем? Очень странное заявление. Нет, ну если, конечно, светодиодом через веб-интерфейс мигать - тогда, конечно, да. Но заявки-то - "хотим 100M через TCP". А теперь давайте считать. Все ОЗУ там - 64кБайт. При скорости в почти 12 Мбайт/с и полностью занятым под буфера TCP ОЗУ максимальный round-trip time, с которым можно обеспечить эту самую дико желаемую всеми цифру - всего 5 миллисекунд.

 

В реальной жизни это означает, что три обычных неуправляемых L2-свича в гирлянде приведут к падению скорости и ничего Вы стандартным построением TCP-стека не сделаете. А если это, скажем, из подсетки в подсетку, разделенные даже адекватной Циской с L3 маршрутизацией - то все, зопа.

[VslavX 0]

Там должно быть то, что позволит полностью использовать возможности конкретного железа.

Это все общие слова. Вы приведите пример для конкретного LPC17xx - чего он уметь-то должен?.

 

Вот у Вас есть то, что Вы назвали "колбек возврата буферов после передачи для хитрой стратегии распределения памяти и квотирования".

И что? Эта неплохая технология позволяет жить и довольно быстро меняться без потери пакетов десятку сокетов, используя всего 16К памяти. Если памяти много и квоты никого не инетересуют, то это ведь можно и отключить.

 

Вы еще мечтаете об использовании аппаратного CRC. Как это ложится на нечто абстрактно универсальное взаимодействие с MAC уровнем массово низводимое разработчиками "универсальных" стеков в своей основной функции до передать/принять фрейм?

Вполне нормально ложится, есть резервное место в поле флагов в пакете (которое при желании расширяется). Если MAC умеет проверять суммы при приеме, то в поле свойств интерфейса будет стоять флажок "а смотрите как я круто умею проверять/считать суммы". И процедура приема пакетов (ессно, версия которая скомпилирована с флагами что у нее могут быть такие умные интерфейсы) просто будет смотреть и проверять во входящих пакетах на таких умных интерфейсах этот флажок, вместо тупого вызова tcp_check_sum. И с отправкой аналогично. В-общем, такой себе out-of-band канал в интерфейсе с MAC-ом должен быть, и это все не моя придумка - идеология подсмотрена в NDIS.