RE: [lwip-devel] Re: [task #7040] Work on tcp_enqueue

[bill]

> I do have writen one (although I wouldn't find it right now), but that
> was written for a NIOS-II with a custom instruction to speed up the
> process. This would be of very little use to any other processor...

This is my direction too (same CPU on the Cyclone III). I first wanted to
wring out as much performance out of lwIP as possible before adding any
hardware optimizations.

Did you do this as an instruction just to read the data and checksum where
lwIP does now, or did you do a DMAing memcpy_chksum?  The latter has the
largest gain you can get by far but does require the checksum to be deferred
to the driver and it obviously has to pick up some smarts about what's there
and what to checksum.  It would be lwIP's version of checksum offloading and
the gain is huge - data is read once and written to the MAC at the same time
while generating the checksum which is then added to the MAC before starting
the transmit.

> > I am looking for the equivalent of:
> >
> > u16_t
> > inet_chksum_memcpy(void *dst, const void *src, size_t len)
> > {
> >   memcpy(dst, src, len);
> >   return inet_chksum(src, len);
> > }
> >
> > (Actually, the simple implementation would work pretty well for me. I
> > have data caches.)

This is worthwhile - perhaps it can be combined for zero-copy - if dst is
NULL don't store the data.

> Of course that depends on the cache size, but it could be a reasonably
> default implementation, since there is always the potential speedup of
> calling the two functions as one (because of cache).

Agree wholeheartedly!

> tcp_enqueue_pbuf could be used by the 'old' tcp_enqueue, after
> allocating and filling the pbufs.

Or tcp_write could build the pbuf and call tcp_enqueue_pbuf.  A user's
tcp_sent could then build an optimally filled pbuf and call
tcp_enqueue_pbuf.  It's not asking too much for this because this case is
either a user using RAW_API (the minority) or other "users" which are
internal to lwIP.

Bill