lwIP PPP netif и Ethernet netif HW/SW checksum, проблемы с аппаратным расчётом контрольной суммы Опции

[eisufu]

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

Код

#if CHECKSUM_GEN_*
  <code>
#else
if ((netif->flags | NETIF_FLAG_POINTTOPOINT) != 0) {
  тот же самый <code>
}
#endif

но сгодилось это лишь для ICMP, TCP уже такое не позволит, так как в функции, содержащие код:

Код

#if CHECKSUM_GEN_*
  <code>
#endif

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

[eisufu]

иметь бы опыт или требования, наводящие на правильный путь, а то бы и пример сгодился альтернативный имеющемуся?)

* "в соответствии с :" — это я про st.com

тестирую запрос-ответ:

CODE

local socket = require('socket')

local client
client, err = socket.udp()
if err then
error(err)
end
local lport = 22222
local laddress = "172.16.0.1"
_, err = client:setsockname(laddress, lport)
if err then
error(err)
end
local rport = 22222
local raddress = "172.16.0.100"
_, err = client:setpeername(raddress, rport)
if err then
error(err)
end
local MAX_PAYLOAD_SIZE = 1472
--local payload = string.rep('@', MAX_PAYLOAD_SIZE)
local payload = ''
for i = 1, MAX_PAYLOAD_SIZE do
payload = payload .. string.char(math.random(0, 0xFF))
end
local n = 0
while true do
--[[
--stalls
local payload = ''
for i = 1, MAX_PAYLOAD_SIZE do
payload = payload .. string.char(math.random(0, 0xFF))
end
]]
_, err = client:send(payload) -- never blocks
if err then
print(err)
else
n = n + 1
print(string.format('send # = %d', n))
end
dgram, err = client:receive()
if dgram then
print(string.format('rcvd size = %d', #dgram))
else
print(err)
end
end

железка выдаёт в обменах/с (возвращает pbuf, который приняла без изменений):

CODE

664.010620
663.129944
664.451843
664.231140
664.010620
663.790222
663.790222
664.231140
663.570007
663.570007
662.471008
662.690552
662.690552
663.790222
664.010620
663.790222
664.010620
664.231140
663.349915
663.570007
663.129944
663.129944
663.349915
664.010620
663.349915
663.570007
663.129944
663.349915
663.790222
664.010620
663.570007
659.630615
661.157043
664.451843
663.570007
663.129944
663.790222
664.451843
663.129944
663.570007
664.231140
664.451843

что-то около 8Mbit/s в каждую сторону. Для железки 168МГц — сносно?

1.3мс реакция (в Wireshark-е смотрел). У компа - 0.2мс рекация.

Код

658.544617 0
658.111206 0
658.544617 0
658.544617 0
656.598816 0
655.307983 0
656.383301 0
654.878845 0
657.030212 0
656.383301 0
658.761536 0

— с закомментированной CHECKSUM_BY_HARDWARE в lwipopts.h
Разница в 1%~. Действительно разницы нет HW или SW checksum.

Сообщение отредактировал eisufu - Jul 24 2012, 09:20

[VslavX]

что-то около 8Mbit/s в каждую сторону. Для железки 168МГц — сносно?

Маловато будет. Сегодня закончил разработку драйвера для 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)

Разница в 1%~. Действительно разницы нет HW или SW checksum.

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

[eisufu]

iperf-ом мерялось

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

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

[VslavX]

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

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

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

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

[eisufu]

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

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

[VslavX]

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

Сложность понятие относительное, зависит от того какие опции протоколов нужны и от общей архитектуры. Если нужны только 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, тем более что его в последнее время развивать стали.