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

[Kais Belgaied]

Sebastien Roy wrote:
> Kais Belgaied wrote:
>>
>> 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?
>
> This discussion veered off a little bit, and I want to bring it back 
> on-topic and make sure that progress is being made on this case.  
> Kais, was your original question answered?
well, not really.
I'm not sure I understand the following argument:
> 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.


does it mean that by default *all* GLDv3 drivers do or are assumed to 
support native VLAN, with the
exception of only a few?

another two unclear points that were brought up by the discussion is the 
interaction of the proposed
capab with with the HW Checksum capability, and with the 
MAC_CAPAB_PERSTREAM:

> We handle MAC_CAPAB_NO_NATIVEVLAN differently in two places:
>
> a. If mac_open() is for a VLAN PPA accessed stream, and the underlying 
> MAC supports MAC_CAPAB_PERSTREAM, but *not* MAC_CAPAB_NO_NATIVEVLAN, 
> we can open the underlying driver directly using its native VLAN PPA 
> access.
>
> b. If the MAC is MAC_CAPAB_NO_NATIVEVLAN, then do not advertise its 
> HW_CKSUM capability on VLAN streams even the MAC claims it is capable 
> of doing HW CKSUM.


>
> To summarize, the only driver expected to implement this is the 
> softmac driver introduced by UV (PSARC/2006/499).  The capability's 
> semantics were defined in such a way to not require every other driver 
> from having to care about its existence.


Ah! in this case, it seems just an internal interface between Nemo and 
itself. If that's true then it's an implemetnation choice and shouldn't be
exposed to device driver writers as part of the MAC_CAPAB* interface 
maturing to soon become committed, and the case can just be withdrawn as 
it turns out to be below the radar for an ARC review.

    Kais.

>
> -Seb
>