Sebastien Roy wrote: > Cathy Zhou wrote: >> 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?). >>> >> How about this: >> >> >> ** HCKSUM_VLANCKSUM bit of MAC_CAPAB_HCKSUM >> >> Today, GLDv3 assumes that all Ethernet MACs that claim HW checksum >> offloading capabilities could do HW checksum for both untagged >> and VLAN-tagged packets. But in reality, there are some drivers that >> can only support HW checksum for packets whose true payload is at the >> right offset (reported in DL_INFO_ACK). For example, they will not be >> able to handle HW checksum for VLAN-tagged packets, as VLAN tag are >> embeded at the start of the payload section, which result in the true >> payload starting at a different offset. >> >> 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 not capable of doing the specified HW checksum offloading >> for packets with extra VLAN tag headers. > > And this is related to UV how?... (you put the answer below, and that's > useful information for the specification) > >>> Do we know of any such drivers offhand? >> I don't know NICs enough to know whether there is such hardware. >> >> But for those legacy drivers unified to GLDv3, UV always chooses not to >> advertise there HW checksum capability on VLAN streams, unless they support >> VLAN PPA access themselves. Therefore, we need a bit to indicate it is >> different from the traditional GLDv3 drivers (that can support HW checksum >> for VLAN frames). > > Got it.
Honestly, I don't know whether this HCKSUM_VLANCKSUM bit is *required* by the UV case. I think we could provide full backward compatibility without adding this bit, by not advertising HW checksum capability if: - this is a VLAN stream, and MAC does not support native VLAN PPA access (MAC_CAPAB_NO_NATIVEVLAN capability is set). But adding this bit can provide completeness, it can be used by GLDv3 drivers (as requested by several person involved in the discussion), and a legacy driver can choose to support HW checksum for VLANs if it would like to. But I would think the latter requires the change of the legacy driver, so that I don't know how likely it is. Thanks - Cathy _______________________________________________ networking-discuss mailing list [email protected]
