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