James Carlson wrote:
> Cathy Zhou writes:
>
>> 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 agree with that path. If we need to support this sort of hardware
> (a bit of a weird design center, if you ask me), it should be a
> separate explicit capability and not just treated as partly-crippled
> margin support.
>
Its a very common approach that I've run into. When you think about
folks designing for switches which either add or strip tags before
before forwarding to other ports, the design makes sense. (Its a lot
less useful for host-based NICs.)
Anyway, this is my point... we need to separate, I believe, the ability
to support VLANs from any ability to do arbitrary encapsulations.
I'd still prefer to treat other encapsulations in the same manner...
assuming that the number of them is small and not expected to grow
much. Right now the only other encapsulation over ethernet that I'm
aware of is RBridges.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
