[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:
>>> 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.
> 
This capability is only known to the Nemo ((including mac and dld) and 
driver layer .

But MAC_CAPAB_PERSTREAM cannot be inferred directly from the 
MAC_CAPAB_NO_NATIVEVLAN capability, because a) the exception of the aggr 
driver, b) some other drivers which are able to support "per-stream" open, 
but only for non-VLAN streams.

The only alternative proposal I can think of is to have MAC_CAPAB_PERSTREAM 
capability to take a value, which indicates whether it can support VLAN as 
well. *Further*, we need a bit in the hardware checksum capability to 
indicate whether the HW CHKSUM can be supported for VLAN or not. But as we 
discussed in another thread, there seems a lot of work other than this is 
needed to be done in the HW checksum area, I am not going to touch that area 
in this fast-track yet.

> 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.
> 
Note that only the GLDv3 framework can see it, and it needs to see it 
because it will behave differently for mac_open(), proto_capability_req() etc.

DLPI clients don't need to know about this at all.

> 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.
> 
Can you tell me how this can help for per-stream-open of the VLAN streams?

> 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.
> 
But that is contradictory to what UV (specifically, the U part) tries to 
accomplish. Also, I don't quite understand why this is related to the 
MAC_CAPAB_NO_NATIVEVLAN discussion.

> 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.)
> 
I agree. But I disagree that Nemo unification is trying to encourage more 
GLDv2 drivers.

Thanks
- Cathy