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

[Garrett D'Amore]

Cathy Zhou wrote:
> 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.

Why bother exposing "MAC_CAPAB_PERSTREAM" anywhere?  (This was what I 
*thought* would have been implied by MAC_CAPAB_NATIVEVLAN).  It seems 
that that capability is (or should be, IMO) exclusively internal to the 
Mac and Driver layer, and never exposed above.

Furthermore, since normal (not legacy) GLDv3 drivers have no way to 
implement CAPAB_PERSTREAM (not ever getting a chance to intercept the 
calls to xxx_open()), I don't think we need it.

What you need, is a way (in the UV framework) to detect legacy drivers 
that have this attribute.  Populating it where others can see it isn't 
terribly helpful.

I think *only* one bit should be needed, MAC_CAPAB_NOTAGGING, which 
indicates to mac clients that the underlying driver (or driver/nemo/UV 
combination) cannot support hardware tagging.

UV can elect to export this bit on any legacy device which lacks support 
for the legacy VLAN PPAs.

For legacy devices that don't support PPA access to VLANs, I'd just give 
them  pass on VLAN support altogether.  They didn't have it on S10 (or 
S8 or S9...) until now, so they must not need it that badly. :-)  And if 
they're going to do something to enable it for Nevada, they might as 
well do a GLDv3 conversion properly.

Certainly, I'd really, really hope that VLAN PPA access methods could go 
away in the not-distant-future.  Frankly, the only NICs that I think 
really need this VLAN support are ce and ge, and I wouldn't complain if 
we did what we could to avoid encouraging GLDv2 drivers from relying on 
it.  (Once S11 ships, or GLDv3 becomes public, we're going to be pushing 
driver folks hard to avoid GLDv2.)

    -- Garrett

>
> - 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
>>
>>
>