On Tue, 2007-07-31 at 13:34 -0400, Andrew Gallatin wrote:
> Garrett D'Amore writes:
> > 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.)
>
> Yes, exactly.
>
> > 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.
>
> Yes.
>
> > 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.
>
> Yes, that would be nice. Which is why I was requesting that we
> don't assume all HCK_PARTIALCKSUM hardware is broken.
Well, we might make that assumption, but then create a new flag for you
to indicate that you can do UDP.
The reason being that we can't assume that all hardware is *working*,
because it clearly isn't, and it will be faster to disable everything
for UDP and selectively add back in, then go and touch *every* Sun NIC
driver (and what other unbundled ones may or may not be broken I don't
know about...)
I think prior to S10, we only did TCP checksum offload, no UDP checksum
offload.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
