Cathy Zhou wrote:
> Garrett D'Amore wrote:
>> One of the problems I've found recently is that some certain legacy
>> devices that should be able to support GLDv3 might not be able to
>> support full size VLAN frames.
>>
>> This creates a problem, as Nemo/GLDv3 does not provide a way for NICs
>> to advertise whether or not they can support such VLAN frames. It
>> would be nice to have a way to indicate to the framework that either
>> VLAN was not supported, or that there was an ethernet MTU
>> limitation. (In fact, *BSD provides just such a facility.)
>>
>> It would be nice to convert older NICs to GLDv3 even in the absence
>> of VLAN support, as they could gain from support for 803.ad link
>> aggregation as well as other newer Nemo features. (Stack instances
>> anyone?)
>>
>> My thought is to create a new GLD capability "MC_NO_VLAN_MTU" or
>> somesuch, which indicates to the framework that full size VLAN frames
>> are not supported. I'm not sure about the amount of code involved in
>> making use of his (perhaps simply disallowing such devices to be used
>> with VLANs altogether?) but I think it would be nice to support.
>>
>> I'd like thoughts on this matter.
>>
>
> The Clearview Nemo unification already proposed to add an ioctl to
> indicate such capability:
>
> "we will introduce a DLIOCVLANINFO ioctl for network devices. The
> underlying driver will acknowledge this ioctl with three different
> values: VLAN_INCAPABLE, VLAN_SIZE_CAPABLE and VLAN_FULL_CAPABLE:
Why ioctls? Is this for the benefit of IP? Or are there other
consumers here that need to know about this?
>
> - VLAN_INCAPABLE The driver cannot handle packets of bigger size,
> i.e., cannot receive or send packets 4 bytes longer than the driver's
> advertised maximum SDU.
>
> - VLAN_SIZE_CAPABLE The driver can handle packets of bigger size.
>
> - VLAN_FULL_CAPABLE The driver is VLAN_SIZE_CAPABLE and can also
> handle the VLAN ppa hack DL_ATTACH_REQ itself."
Is there a reason for this to be exposed to drivers? I don't like the
idea of spreading around (or encouraging the spread) of code to do the
PPA hack itself. (Or is this for Cassini's benefit?)
>
> In addition to that, we also added a GLDv3 MAC capability
> MAC_CAPAB_LIMITED_VLAN to indicate this legacy device is either
> VLAN_INCAPABLE or only VLAN_SIZE_CAPABLE.
I'd like to think that only VLAN_INCAPABLE is needed. I can';t imagine
a need to distinguish, at the mac layer, between VLAN_SIZE_CAPABLE and
VLAN_FULL_CAPABLE. (See my earlier comments.)
And really *any* ethernet device should be VLAN capable (barring the
existing of some broken device that won't accept arbitrary ethertypes...
I can't imagine such a beast existing), its just that it might have to
use a reduced frame size.
So, maybe all we need is to indicate MAC_CAPAB_VLAN_MTU_LIMITED or
somesuch. Makes it even easier for driver developers. :-)
-- Garrett
>
> Thanks
> - Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
