[EMAIL PROTECTED] wrote:
Whilst chasing down a bug with bge and flags for hardware checksum, I noticed that GLD is currently quite permissive in the combinations of flags that it allows:dlhp->hcksum_txflags = 0; if (macinfo->gldm_capabilities & GLD_CAP_CKSUM_PARTIAL) dlhp->hcksum_txflags |= HCKSUM_INET_PARTIAL; if (macinfo->gldm_capabilities & GLD_CAP_CKSUM_FULL_V4) dlhp->hcksum_txflags |= HCKSUM_INET_FULL_V4; if (macinfo->gldm_capabilities & GLD_CAP_CKSUM_FULL_V6) dlhp->hcksum_txflags |= HCKSUM_INET_FULL_V6; if (macinfo->gldm_capabilities & GLD_CAP_CKSUM_IPHDR) dlhp->hcksum_txflags |= HCKSUM_IPHDRCKSUM; Thus it would seem plausible for a GLD queue to become active a full set of the above set... If we were using a single queue for IPv4 and IPv6, this would fit in with the above. Is that a slated goal for the future? Or should the above be a bit more stringent and report an error if full v4 and full v6 are being attempted or iphdr on v6, etc?
I'm not sure I understand the problem. Basically, it seems like bge is saying it can support V4 checksum. The fact that this is exposed on a V6 stream is slightly unfortunate, but I think it would be harmless, since the consumer of this flag (IP) should ignore the checksum flag on a v6 stream.
So, an extra flag set on the stream should be harmless. Or am I misunderstanding?
At present, bge interfaces for IPv6 are quite happily advertising IPv4 header checksum as well as full offload for IPv4 :-) Imposing some restrictions would discourage that kind of nonsense and perhaps make those types of bugs more obvious? See 6564327 for further details on the bge issue.
Btw, your code above is from GLDv2, but bge uses GLDv3. -- Garrett
Darren _______________________________________________ networking-discuss mailing list [email protected]
_______________________________________________ networking-discuss mailing list [email protected]
