[ For people who does not see previous discussion, please first have a look of the fast-track draft:
http://opensolaris.org/os/project/clearview/uv_addendum_fasttrack ] > I've been thinking more about the proposal to advertise "margin" > information, and I'm a bit uncomfortable with it. > > I believe that there is a class of NICs that supports VLAN tag insertion > and removal, but does not support packet payload sizes over the standard > 1500 MTU. (Or 9000 for NICs supporting Jumbo Frames.) These NICs > usually have "hardware VLAN offload", which is just a fancy way of > saying that they can automatically insert the VLAN tag from meta data > (descriptor fields that aren't part of the packet usually), or strip the > tag (and report it in a descriptor) on receive. > > Right now the support for this feature is clumsy because it requires > software parsing of the packet ethernet headers, or manual > reconstruction of the ethernet header, to make it work. Kind of clumsy, > but basically functional, and not a huge performance hit. > 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. Note that the definition of "margin" is: "extra room in the payload section besides the maximum SDU size reported in DL_INFO_ACK. The extra room (margin) can be used to provide additional headers." By definition, the margin should be general purposed, and it is useful if we have to embed additional headers in the payload *transparent to" the driver. For those drivers which can support VLAN tag insertion/removal though, the extra 4 bytes cannot be used for other additional headers but VLAN tags, they should only announce their margin to be 0. That means in order to support VLANs over such driver, we'd need another approach to indicate its VLAN tag insertion/removal capability. But the difference between "the margin capable" and "the VLAN tag insertion/removal capaple devices" should be made, because the way they handle the extra VLAN tag is different. I'd like to hear from the Nemo team what's their opinion about this. Thanks - Cathy > But, this feature doesn't mean that one can arbitrarily add non-VLAN > tagging data to the packet. Specifically, it *may* require that the > packet have the tagged VLAN ethernet type. (I.e you may not be able to > use those extra 4 bytes for anything else!) > > I'm also a bit unhappy with the idea of building protocols which rely > upon the ability to "arbitrarily" extend the packet size. For VLANs we > added an encapsulation layer. For Rbridges, I suspect what we should do > is add another "capability" bit which says that the device can add an > Rbridge encapsulation layer. (Notably, IIUC, only the *rbridge* needs > to be able to do encapsulation/decapsulation... end nodes don't need this.) > > I don't know what the interaction between Rbridges and VLANs is. Maybe > someone else can enlighten me. > > I guess what I'm saying is that I'd prefer to handle these oddball cases > of encapsulation as one-off capability bits rather than a randomly > chosen "threshold". > > Are we expecting there to be other cases were different encapsulations > are needed? > > -- Garrett > > > > > > _________________________________ > clearview-discuss mailing list > [EMAIL PROTECTED] _______________________________________________ networking-discuss mailing list [email protected]
