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. Drew _______________________________________________ networking-discuss mailing list [email protected]
