Создаю два интерфейса - один Ethernet (STM32F4x7 Ethernet controller настроен на hardware checksum), другой - PPP over serial. lwIP в lwipopts.h имеет настройки того, как будет считаться контрольная сумма: аппаратно или программно. Конечно, для PPP железо не считает контрольную сумму, интерфейс-то — "виртуальный". Попробовал следующее: везде в коде lwIP, где встречаются CHECKSUM_GEN_* (IP, TCP, UDP, ICMP) добавить код

но сгодилось это лишь для ICMP, TCP уже такое не позволит, так как в функции, содержащие код:
не передаётся netif *, для которого формируется пакет TCP. Да и вообще пришёл к выводу, что контрольную сумму надо считать централизованно для PPP (на камне есть периферия, которая быстро считает CRC), а для остальных netif - в зависимости от дефайнов CHECKSUM_GEN_*, зависящих от CHECKSUM_BY_HARDWARE.
Масса исходников — сходу не могу понять, где это "узкое место" где проходят все пакеты для каждого из IP, TCP, UDP, ICMP. Каково красивое решение?

Спасибо

Маловато будет. Сегодня закончил разработку драйвера для EMAC STM32Fxxx, с опциональной/отключаемой поддержкой аппаратных сумм - сам драйвер более 4 тыс строк, с использованием RTOS. На F207@120МГц результаты такие (поток в одну сторону, iperf-ом мерялось):
С отключенными суммами (скорость указана в "полезных" байтах TCP-соединения, теоретический предел порядка 96 мбит/сек):
- прием от PC - 95.7 мбит/сек, загрузка процессора 77 процентов (23 в IDLE остается еще)
- передача на PC - 87.8 мб, загрузка процессора 59 процентов (41 в IDLE)
С включенными аппаратными суммами:
- прием от PC - 95.7 мбит/сек, загрузка процессора 55 процентов (45 в IDLE)
- передача на PC - 88.4 мб, загрузка процессора 51 процентов (49 в IDLE)


Как показывают приведенные цифры - заметная разница вылазит только на относительно больших скоростях. Ваши потоки на порядок меньше, соответственно и разница тоже на порядок меньше (22 процента разделить на 10 - пару процентов и выходит). Справедливости ради надо заметить, что я обломался с написанием обработки специфических ошибок DMA передатчика и в обоих случаях (с суммами и без) контроллер работает в режиме Store-And-Forward, этим я объясняю недостижение передатчиком теоретического максимума в 96 мбит/сек.

Я смотрю, зацепил я Вас в той теме со стеком. Цифры у Вас явно выше тогдашних, поздравляю

Что иллюстрирует следующую мысль: чтобы выжать из железа все соки, надо попыхтеть. Если эти 100 Мбит на практике не нужны, то лучше направить свою энергию в более конструктивное русло.

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




TCP/IP стек - это универсальный кубик, его можно применить в любом проекте, не ограничивая себя теми,
где "эти 100 Мбит на практике не нужны". Например этот же "кубик" у меня стоит в проекте где и гигабита маловато.

Уже польза.

Сложно серверную сторону на железе поднять?

стек вы реализовывали или готовый использовали?

Несложно, клиентскую тоже несложно. Если нужен сервер - то ждете соединение (listen), принимаете его (accept) и на новом TCP соединении просто осуществляете прием с отбрасыванием всех поступивших данных (естественно на уровне приложения, а не стека), при желании измеряете текущую скорость на стороне сервера, когда соединение закрывается - цикл можно повторить. Никаких специальных данных в потоке iperf не требует.


Реализовывал свой, ничего из готового на тот момент не устраивало.

Какие протоколы? Какие сложно реализовать?

Сложность понятие относительное, зависит от того какие опции протоколов нужны и от общей архитектуры. Если нужны только ARP/IP/ICMP/UDP без особых наворотов (без IP-опций, без фрагментирования, не заморачиваясь с фичами типа zero-copy) то можно даже не напрягаться и взять уже что-то готовое. Но мне был нужен минимальный комплект ARP/IP/ICMP/UDP/TCP/DHCP/AutoIP/DNS/HTTP/SSDP, да в разные проекты, да на долгую перспективу, да endainess-portable, да на работе вытерпели (читать - дали время, повезло мне) - поэтому решил сделать свой.
На 2008-ой год, когда писалась основная часть, изучал многие готовые стеки (uIP, lwIP, Niche, ka90, tinet, OpenTCP) . На мой взгляд самый внятный это lwIP. Поэтому если свой стек нет возможности писать - то я бы остановился на lwIP, тем более что его в последнее время развивать стали.

Уверен: великолепный опыт. Но думаю хотя бы PPP реализовывать самому - сложное занятие, так что выбираю lwIP.
Интересно, каким образом близкие к 100Mbit/s выжимали из STM32F4x7 из lwIP... Кто-нибудь может поделиться опытом? Очень интересно.