[ECOS] TCP/IP checksum routine performance

[Andrew Lunn]

> 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).  So far,
> experiments and source code examination _seem_ to support that
> assumption.  If not, I'll need to add some special-case code to
> handle that.

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.

> It looks like the
> optimizer tries to postpone calculations (the "add"
> instructions in the example below). This leaves a lot of needed
> data in registers. When it does decide to do the operations it
> runs out of registers and has to shuffle stuff around (is
> "register thrashing" a good term?). For instance, here is the
> code for the inner checksum loop which sums 32 bytes per
> iteration.

Probably a good idea to cross post this to the gcc list. Those readers
may have a better idea whats going on inside gcc.

        Andrew