2008/242 Data Fast-Path for Softmac

[Darren Reed]

Cathy Zhou wrote:

> Darren Reed wrote:
>
>> Sebastien Roy wrote:
>> ...
>>
>>>        Note that some GLDv3 features requires the GLDv3 DLS/MAC layer
>>>        processing to not be bypassed to assure its function 
>>> correctness.
>>>        For example, softmac fast-path must be disabled to support GLDv3
>>>        VNIC functionality. As the result, we propose: By default, the
>>>        softmac fast-path mode will be used to assure the 
>>> performance; MAC
>>>        clients will be able to request to disable the softmac fast-path
>>>        mode to support certain features, and if that succeeds, the 
>>> system
>>>        will fallback to the existing softmac data-path model (called 
>>> slow-path).
>>
...

>> Can the architecture of this project be changed or expanded
>> to include dealing with the VNIC functionality problem?
>>
> I am not clear what your question is. Note that VNIC is going to be 
> supported on legacy device as part of this case. But once VNIC is 
> configured, fastpath will be disabled.


Let me approach this from a different angle...

What sort of architectural problems exist that prevent this
fast-path project from being extended to supporting VNICs?


>>>        2. For IP/ARP streams over a softMAC, softmac data fast-path 
>>> will be
>>>           used by default, unless fast-path is disabled by any MAC 
>>> client
>>>           explicitly. The softmac module first identifies an IP/ARP 
>>> stream
>>>           by seeing whether there is a SIOCSLIFNAME ioctl sent from 
>>> upstream,
>>>           if there is one, this stream is either an IP or an ARP stream
>>>           and will use fast-path potentially;
>>
>>
>>
>> Why are you looking at the SIOCSLIFNAME ioctl rather than
>> the bind?  As defined, SIOCSLIFNAME does not appear to be
>> IP specific at all, aside from our implementation and use.
>>
> I thought SIOCSLIFNAME is a private ioctl and should not be used by 
> others other than IP. Please correct me if I am wrong.


Let me approach this from a different angle...

Architecturally,  you seem to have chosen to use a private
ioctl that has some predefined characteristics that _imply_
IP rather than a public one (the bind) which informs you
exactly about whether or not it is IP, ARP, etc.  That is
the choice to use SIOCSLIFNAME as the trigger appears weaker
than using the bind. Why did you make this choice?

Darren