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). > 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. Thanks - Cathy > Drew _______________________________________________ networking-discuss mailing list [email protected]
