This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: TCP/IP checksum routine performance



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 :-)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]