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

[Cathy Zhou]

Garrett D'Amore wrote:
> Cathy Zhou wrote:
>> 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.
> 
> Okay, I'm confused.
> 
> GLDv3 drivers do *not* handle PPAs at all.  They are totally ignorant of 
> the DLPI, and even of VLANs...  the only things a GLDv3 driver knows 
> directly about (normally) is
>   a) instance numbers... each driver normally knows that it has a common 
> instance number (which ultimately gets translated to the PPA for 
> untagged packets, but that is incidental)
> 
> b) tagged packets (which might be for VLANs, or might be for QoS 
> tagging) are bigger.  All GLDv3 drivers *today* can cope with the extra 
> 4 bytes required for tagging.
> 
> What exactly does MAC_CAPAB_NO_NATIVELAN convey?   Put another way, if 
> *all* current GLDv3 NICs qualify as having a "native vlan support" 
> (which right now most just support a bigger packet size), then it is, 
> IMO, silly to try to emulate above them.
> 
> In otherwords, what will UV do with devices that have 
> MAC_CAPAB_NO_NATIVEVLAN?  Will they get "something special" (some 
> different kind of VLAN emulation layer?)  Why?
> 
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.

- Cathy

> I think it makes far far more sense for UV (and not just UV, but Nemo) 
> to just have
> 
>    MAC_CAPAB_NO_TAGGING
> 
> which covers all legacy drivers that lack full support for tag 
> insertion. 

 > This means that those drivers won't support VLANs at all
> (and I don't think your -F workaround is a good idea, because it will be 
> a call generator and because I think such hardware is now so old to be 
> uninteresting, especially given the readily available options... the 
> only common PCI legacy NICs I know with that problem are 3Com elxl, 
> which is, AFAIK, due to be EOL'd.
> 
> All the "interesting" legacy NICs (which is, IIUC, 90% for ce at this 
> point, because most of the others are already converted, excepting 
> perhaps a few rarer 3rd party NICs) are already converted to GLD.  
> (There are mostly uninteresting ones, like pcelx, which hasn't been on 
> the market for a very long time....)  I'll convert the rest of the NIC 
> drivers in ON as soon as I have a way to express the equivalent of 
> MAC_CAPAB_NO_TAGGING.  Then only the 3rd party ones... and ce and gem... 
> will matter.  (And I'll probably do gem soon as well, once I get access 
> to the hardware... Its almost identical to the work I've already done 
> for eri. :-)
> 
>    -- Garrett
> 
>