[EMAIL PROTECTED] wrote:
Adi Masputra wrote:
[EMAIL PROTECTED] wrote:
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.
So what's the real problem? Hardware checksum state is on
a per-packet basis. Regardless of the number of open streams
to the driver, packets from different streams end up in the
same tx ring(s), and each tx descriptor has the flag that says
whether or not the NIC should compute the checksum during DMA.
To me it seems somewhat silly and nonsensical to be advertising
IPv4 capabilities on IPv6 network interfaces and vice-versa.
Maybe it doesn't hurt anything, but to me it looks sloppy.
If the model is changed where a network interface supports both
protocols, sure, no problem.
For a GLD drivers (both v2 and v3), the driver is totally ignorant of v4
vs. v6 streams. In fact, the driver doesn't know about streams at all
(minor exception in the case of ioctls, but that is only so the driver
can send the reply message back to the right stream.)
Now, if you're saying if the GLD framework(s) need correction here, then
that is a different thing.
And, has been pointed out, the state is such that the flags are
harmless. For transmit, the consumer can elect whether or not to send
down a packet with the request for checksum support. For receive, the
packets come upstream with an indication that the checksum is complete.
Its up to the consumer to decide whether to trust that or to calculate
the checksum on its own in software. (And if the consumer is ignorant
of the hardware checksum, then it can always just use software.)
Now, there is a _different_ problem that this raises, which is that
there has been an RFE outstanding for the ability to disable h/w
checksum in the drivers. The problem with this is that for tx, ti
requires the drivers to be able to send a message upstream to the stack
informing it of a state change in whether checksums are supported or
not. I don't believe that this is supported in the current GLDv3
notification mechanism, though I could be wrong. (For rx, its trivial,
because the driver can just not supply the rx checksum tags on the mblks.)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
