I just wish we were a step ahead instead of 2 steps behind.

Rob

Garrett D'Amore wrote:
> Cathy Zhou wrote:
>> Erik Nordmark wrote:
>>> Sebastien Roy wrote:
>>>
>>>> Interfaces
>>>> ==========
>>>>
>>>>     - mac_fastpath_disable()/mac_fastpath_enable() (Consolidation 
>>>> Private)
>>>
>>> Why can't those be project private? Presumably no MAC driver other 
>>> that softmac should ever use this.
>>>
>> These are not used by softmac driver. They are used by mac clients. 
>> At this point only the vnic driver will need to call these functions. 
>> But it could be used by any MAC clients that don't work with fast-path.
>
> So the mac clients need to be aware of fast path?  That sounds rather 
> unfortunate -- given that the ultimate goal is to expose the mac 
> client API someday.  It seems like the details of this should be an 
> implementation detail, that mac clients don't have to worry about.
>
> Perhaps more clearly, I don't want MAC clients to fail to function 
> correctly if they don't enable this behavior.
>
> I'd rather have an explicit "enable" that is used by fast-path aware 
> clients (probably only the IP stuff), and let all other clients 
> automatically start without fast path enabled.  That way if someone 
> writes a mac client that doesn't know about fastpath, it will at least 
> function properly.
>
> (Yes, I still believe that this whole fastpath mechanism is 
> essentially a performance hack to work around a few crufty drivers 
> that really should be updated to be pure GLDv3 drivers instead of 
> moving this cruft into the framework.  But on the assumption that 
> we're going to move forward with this, lets at least limit the 
> visibility of this API to minimize its architectural impact on the 
> system.)
>
>    -- Garrett

Reply via email to