This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: TCP/IP checksum routine performance
- To: Grant Edwards <grante at visi dot com>
- Subject: Re: [ECOS] TCP/IP checksum routine performance
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Fri, 28 Apr 2000 10:18:44 -0600 (MDT)
- Cc: ecos-discuss at sourceware dot cygnus dot com, Andrew Lunn <andrew dot lunn at ascom dot ch>
On 28-Apr-00 Grant Edwards wrote:
> On Fri, Apr 28, 2000 at 05:55:20PM +0200, Andrew Lunn wrote:
>
>> > I've made a possibly dangerous assumption that the only time an
>> > mbuf will contain an odd number of bytes is at the end of a
>> > chain (IOW, a 16-bit word is never split across mbuf
>> > boundaries).
>>
>> My guess is you are quite safe with this assumption. This code
>> came from a UNIX system which is quite likly to have DMA
>> engines. A lot of DMA engines don't like transfering less than
>> words, especially when in scatter/gather mode. Just to be safe
>> you could add an assertion, so if it does blow up we know why.
>
> Yea, I've got a test in there now. I'm pretty sure that none
> of the standard protocol code is going to try to split a word.
> IP and TCP headers are always in their own mbufs, and I don't
> think that TCP data segments are going to get split at odd byte
> boundaries. I also can't see any way that it could be made to
> happen by user application code. But, somebody went to a fair
> amount of trouble to make the current routine handle it, so I'm
> a bit uneasy.
>
I also am not convinced this will ever happen, but it's best to
err on the safe side.
>> Probably a good idea to cross post this to the gcc list. Those readers
>> may have a better idea whats going on inside gcc.
>
> I'm going to try to generate a simpler, stand-alone source file
> that demonstrates the phenomenon. Right now, in order to get
> the mbuf struct definition you end up with the entire set of
> network headers pulled in just to compiler the checksum routine
> (which isn't too convenient for the compiler-hacker).
>
I have already made sure that the ARM GCC maintainers are aware of
your findings.
Thanks for digging into this so deeply - we'll all benefit in the end :-)