tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: hme(4) hardware RX checksum wrote:

> Have you read this:
> 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:

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

Home | Main Index | Thread Index | Old Index