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 мбит/сек.

[Rst7]

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

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

[VslavX]

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

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

Если эти 100 Мбит на практике не нужны, то лучше направить свою энергию в более конструктивное русло.

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