Sebastien Roy wrote:
> Cathy Zhou wrote:
>> I am adding this in the PSARC fast-track, and the diffs are posted
>> below. The following link is also updated
>>
>> http://opensolaris.org/os/project/clearview/uv_addendum_fasttrack
>
> ...
>
>> + ** HCKSUM_VLANCKSUM bit of MAC_CAPAB_HCKSUM
>> +
>> + The HCKSUM_VLANCKSUM bit can be set in combination with other
>> + MAC_CAPAB_HCKSUM bits (HCKSUM_INET_PARTIAL, HCKSUM_INET_FULL_V4,
>> + HCKSUM_INET_FULL_V6, or/and HCKSUM_IPHDRCKSUM), to indicate that
>> + a MAC is capable of doing the specified hardware checksum
>> offloading
>> + for VLAN frames.
>
> Can you add to the specification an explanation of why this is needed?
> In other words, GLDv3 previously (wrongly) assumed that all devices
> which claimed to support various flavors of hardware checksum offload
> could so with VLAN-tagged frames. This flag is presumably needed for
> some potential drivers out there that do hardware checksum, but only
> for non-vlan-tagged frames (correct?).
>
> Do we know of any such drivers offhand?
Furthermore, since its apparently easy to deal with restrictions on RX,
its only a problem for drivers that have this restriction on the TX side.
I still believe that a much better solution would be to offer drivers a
way to "Punt" on a packet. E.g. HME/QFE cannot offload checksum for
tiny packets due to a chip bug. I suspect other chips might have
problems offloading checksum for packets that have other physical
properties (crossing a page boundary for jumbo frames, or maybe frames
that need to use scatter/gather DMA?)
While we're talking about checksum, there is still also the case that
most (all?) Sun NICs don't do UDP checksum offload properly... that is
they cannot deal properly with the case where the IP checksum result is
0. UDP requires that the value 0xffff be stashed instead (which is
different from TCP), with the result that non-conformant frames may be
put on the wire.
To deal with this, I believe that we really need to separate partial
checksum calculation for TCP vs. UDP.
-- Garrett
>
> -Seb
_______________________________________________
networking-discuss mailing list
[email protected]
