On Tue, 2007-07-31 at 12:31 -0400, Andrew Gallatin wrote:
> Garrett D'Amore writes:
> > On Tue, 2007-07-31 at 08:58 -0400, Andrew Gallatin wrote:
> > > Garrett D'Amore writes:
> > > > I suspect that we will need to stop using TX checksum offload for one
> or
> > > > the other of TCP or UDP, at least for NICs that do partial checksum
> > > > offload. (Having, of course, a nasty performance impact on the other
> > > > side.)
> > >
> > > Can you please do this per-driver, or at allow an exemption for
> > > hardware which is not broken?
> >
> > Sorry, I only meant "partial checksum". Do you know of any
> > implementations of "partial checksum" that are not broken?
>
> Myri10ge, for one..
>
> But wait, maybe I mis-understood what you mean by "partial". Your
> reference to software workarounds for tiny packets confused me. I
> think of partial as HCK_PARTIALCKSUM. Or did you mean sometimes doing
> the checksum in hardware, and sometimes in software?
No, I mean HCK_PARTIALCKSUM.
So does Myri10ge support this variation of checksum, and is somehow not
broken with respect to UDP vs. TCP and zero checksums? (Recall that
when the UDP checksum results in a zero value, UDP requires that
all-ones (0xffff) be transmitted instead, to differentiate it from
packets with checksum disabled (checksum = 0). For TCP (and pretty much
all other protocols that use this checksum operation) checksum is always
used, and a zero checksum is sent unmodifed as 0.)
I can imagine that the only way for hardware to get this "right" is to
examine the IP protocol field. Since that is not part of the data that
is covered by the checksum, it implies that there is some classification
done in either software or hardware, to pick which interpretation for
the zero result to use.
It shocks me that IETF would have been so cavalier about this seemingly
minor difference.
If you have hardware which can do "the right thing" depending on which
protocol is used (or upon instruction from the driver), then perhaps we
need a way to differentiate that behavior for your driver's benefit.
-- Garrett
>
> Drew
_______________________________________________
networking-discuss mailing list
[email protected]
