[clearview-discuss] 2007/527 Addendum for Clearview Vanity Naming and Nemo Unification

[Cathy Zhou]

Garrett D'Amore wrote:
> Kais Belgaied wrote:
>>>      ** MAC_CAPAB_NO_NATIVEVLAN
>>>
>>>         A MAC_CAPAB_NO_NATIVEVLAN MAC capability will be added to the
>>>         GLDv3 framework to indicate that a specific MAC cannot support
>>>         VLAN PPA access by itself.
>>>   
>> this sounds a little upside-down.
>> A driver has to advertise a negative capability, essentially saying 
>> "Hey, I can't handle this feature"
>> as opposed to the more intuitive approach: drivers that can handle 
>> native VLAN expose a capab (MAC_CAPAB_NATIVEVLAN),
>> and those who don't do not.
>> Any reason for this choice?
> 
> It sounds really odd-ball to me, too.  Plus, it would require touching 
> all the existing GLDv3 driver.  

No. We introduce MAC_CAPAB_NO_NATIVEVLAN exactly for the reason that we do 
not want to touch most of the GLDv3 driver. MAC_CAPAB_NO_NATIVEVLAN means 
that this driver cannot handle VLAN PPA access itself (therefore, it might 
also implies that this driver does not handle the hardware checksum for VLAN 
packets). Existing GLDv3 drivers should *not* advertise this capability, 
except the aggr driver, which might based on the underlying aggregated drivers.

- Cathy

Yech.  Far, far better to add
> MAC_CAPAB_NATIVEVLAN (or even better, MAC_CAPAB_VLAN_PPA, which more 
> accurately describes  the feature.)
> 
> Of course, IMO, this is really, really weird, because *today* Nemo 
> drivers are totally ignorant of PPAs, as such.  I'm not sure how a Nemo 
> driver with this feature would act... what causes a VLAN PPA attach to 
> happen.  But there is lot about clearview that I don't completely 
> understand.
> 
>     -- Garrett
>>    Kais.
> 
> 
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org