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

[Garrett D'Amore]

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?

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