Cathy Zhou writes: > Andrew Gallatin wrote: > > Cathy Zhou writes: > > > My personal take is that this is due to GLDv3 does not support HW VLAN > > tag > > > insertion/removal, so that such driver has to do the parsing/encoding > > > itself. Ideally, this parsing/encoding should be done by the GLDv3 > > framework. > > > > If and when GLDv3 grows the ability to parse/encode VLAN tags, I > > really hope that it is optional and not tied to however the "margin" > > is treated. > > > > If we are going to go through this path - that we will add a VLAN tag > insertion/removal GLDv3 capability, the driver could choose not to advertise > this capability, but instead report its margin value to be greater than 4. > So that GLDv3 will simply treat the VLAN tag as part of the payload section > and send it to the driver (and receive it from the driver).
Yes! > > My 10GbE NIC does not do HW VLAN tag insertion/removal (we concluded > > there was no performance benefit). On several OSes, I'm forced to > > claim the device does HW VLAN tag support (and do tag > > insertion/removal in the driver) to gain support for the 4 bytes of > > "margin" (1518, 9018), and/or to get the OS to trust that my device > > can offload checksum in combination with VLAN frames. > > > Hmm, can we make the assumption that supporting margin of greater than 4 > always implies that a driver can handle offload checksum for VLAN frames? I > am not sure whether this is always true. Maybe there could be a capability flag for checksum offload in combination with vlan? There seem to be plenty of bits free in the 32-bit cap data for MAC_CAPAB_HCKSUM. Drew _______________________________________________ networking-discuss mailing list [email protected]
