Re: hme(4) hardware RX checksum

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

darrenr%NetBSD.org@localhost wrote:

> Have you read this:
> http://gdamore.blogspot.com/2007/08/hme-checksum-limitations.html
> 
> You might want to follow up with Garrett directly, to see
> if he has any tips/comments on the hardware itself.

Hmm, it mentions TX hwsum and I just tweaked RX hwsum.

Anyway, our hme(4) driver (and hardware?) only supports
dumb TX csum for TCP and UDP (not for IP header csum),
and I guess most TCP packets always >64 bytes in these days.

I also tested some UDP packets but can't see wrong sums on RX side,
though I could be wrong.

> > Currently hme(4) and gem(4) have the similar code which decodes
> > RX packet headers to adjust (deducting IP option sum etc.)
> > a dumb checksum data provided by hardware.
> > fxp(4) (i82559) also has the similar RX checksum hardware so
> > I wonder how we can share a common function to decode RX packets
> > for such dumb RX M_CSUM_DATA checksums.
> ...
> 
> With respect to this question, yes, it seems that it might
> be a worthwhile idea for this functionality to bubble up
> into the common ethernet code.

Currently the following device use the functionality:
 sys/dev/ic/gem.c
 sys/dev/ic/hme.c
 sys/dev/ic/i82557.c
 sys/arch/sgimips/mace/if_mec.c

We'll have to consider to define an MI API after
we will see another quirk in 5th one... (msk(4) etc?)

The common function will take RX mbuf and return
a usability of the dumb sum (TCP/UDP/not applicable) and
an offset of data in the packet for the actual sum?

---
Izumi Tsutsui