Re: [lwip-users] inet_chksum.c misbehaving with compiler optimisation?

[Enrico Murador - Research & Development - CET]

As Simon said, if checksum calculation is the most time consuming task in lwIP,
maybe without optimization the ethernet driver is fast enough to never see more
than one packet at a time; could it be that only with optimization the driver has to
handle more than one packet in the DMA queue, and it fails to do it for some reason?

Sorry if I'm wrong, I'm not so confident with TCP/IP and LwIP, hope it could help anyway...

Enrico

On 22/11/2011 22.29, FreeRTOS Info wrote:

On 22/11/2011 20:13, address@hidden wrote:

FreeRTOS Info wrote:

Just in case anybody is watching this thread:

As unlikely as this all seems, having previously isolated one file, I
have now isolated it to a single function: lwip_standard_chksum().

I have the entire applicatino running at maximum optimisation, except
this function, and everything is happy.

Put the lowest optimisation on just this single function (which is now
in its own file), and the network works, but with a lot of corruption on
the wire.

Like Kieran and Stephen, I wouldn't rule out the possibility of a timing
issue, too. Especially since checksumming was the most time consuming
task in lwIP when I last benchmarked (aside of memcpy, but I guess you
haven't changed the amount of optimization of memcpy in your tests as it
often comes precompiled with the C library).

Nevertheless, to prove the function fails, why don't you run a test on
random data comparing the results of the optimized checksum function
with a non-optimized version? You can even let that test run for a while
if you put the two functions into the same binary. If it's a compiler
bug or anything in that area, this test should show it.

BTW: what do mean with 'a lot of corruption on the wire', invalid
checksums or more errors?

Ok, as would hopefully be expected, checksumming dummy arrays produces
the same result with and without the function in question being
optimised.  That is good, so I should stop going down that dead end.
Thanks for the suggestion, I should have thought to do that myself, doh!

BTW: what do mean with 'a lot of corruption on the wire', invalid
checksums or more errors?

There were inexplicable frames in the log of an unknown protocol.
Wireshark was attempting to decode them as xyz or whatever protocol
(nothing I had heard of), but when I looked into the frames using
wireshark they were corrupt anyway.  That was quite concerning, and
first lead me to look at the driver code (which is still looking like a
good candidate).

I have attached the logs as they look now, and they don't show any
strange data at all, but do show the problem with retransmissions.
Good.pcap is without optimisation in the checksuming, bad.pcap is with
optimisation in the checksumming.  192.168.0.200 is the target.

I would be grateful if you could elaborate on the timing theory.  I
presume it is because the speed is causing a resource to be exhausted,
but where shall I look first.  I checked the stats array some time back,
and could not see any error counts incremented.  I also tried to get
some debug prints out, but unfortunately the target I have does not make
that easy without the CPU being held in debug state for the entire print
out (I could write a UART driver and shove the message out there though).

The DMA buffers are squeezed into 16K of RAM.  I could try increasing
those, but there is very little room.

Regards
Richard.

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users