2008/242 Data Fast-Path for Softmac

[Cathy Zhou]

Darren Reed wrotecture 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?
> 
I can give an example here: assumes there is a VNIC (vnic0) configured on 
legacy device (say, ce0), we could plumb vnic0 and ce0, and the traffic sent 
over ce0 needs to loopback by the MAC layer if the traffic is destined to vnic0.

In the case that fast-path is used, traffic sent over ce0 will directly passed 
to the softmac and will skip the MAC layer, and cannot be looped back to vnic0.

> 
>>>>        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?
> 
Because we needs to determine whether the upstream is a "fastpath candidate" 
at the very early phase when the upstream is plumbed. Each DLPI control 
messages (including the ones comes before DL_BIND_REQ) will then be directly 
passed to the underlying dedicated lower-stream, or be passed to the normal 
GLDv3 processing, based on whether fast-path is used or not.

Thanks
- Cathy