Garrett D'Amore wrote:
[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?
The problem is tied to TCP/IP, where checks are made to see if either
flag is set, without checking to see if the flag matches the stream.
The partner in crime here is uts/common/ip/tcp/tcp.c:tcp_multisend().
While the IPv4 header flag set on an IPv6 stream is harmless, it just
seems wrong to see it advertised there? The same as fullv4.
What I'm assuming is that the card also supports fullv6 (or else some
TCP transfers over bge would just fail) but that this isn't indicated at
all.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
