Cathy Zhou wrote:
> 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.
>>
> Unfortunately, because softmac is not able to know whether some
> specific function can work with the fast-path data-model or not, mac
> clients have to specify that information.
Yech. I'd be far far happier if mac clients only needed to specify that
*if* they needed the performance of fast path.
Notably this seems to be required only for legacy links, which (imo)
defeats much of the purpose of the Clearview project, which is to shield
clients from knowing or having to deal differently for legacy versus
native GLDv3 NICs.
Architecturally, this seems unsound (exposing MAC clients to the details
of underlying device plumbing).
>
> But I think you made a valid point that these two functions should be
> classified as "Project Private" today, as all other mac client
> interfaces are all "Project Private" today (defined in PSARC 2004/571).
>
> I will make these changes to the case material.
Okay, that's a start.
>
>> 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.
>>
> Note that VNIC is currently the only mac client that does not work
> with fastpath. Aggregations (for example) can co-exist with fast-path
> just fine. Further, even we assume IP is the only mac client which
> works with fast-path, we have to have some kind of mac client
> interface to tell the difference: assume that IP is plumbed on a
> legacy device, and fast-path is enabled explicitly, then some other
> mac client starts to use this legacy device and it does not work with
> fast-path, we still need to disable fast-path dynamically. More
> important, when that mac client goes away, and IP is now the only one
> user of this legacy device, then we should fall back to the fast-path
> again.
Yes, but I don't think you gain much simplicity by having disable be
explicit. The same problem exists. (Dynamically enabling or disabling
fast path.)
-- Garrett
>
> Thanks
> - Cathy
>
>> (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
>>
>> _________________________________
>> clearview-discuss mailing list
>> clearview-discuss at opensolaris.org
>
