Sebastien Roy wrote:
> I'm taking this off of PSARC-ext for now because I really don't think
> that this discussion is making adequate progress, and we risk flooding
> the fast-track with design discussions. Let's get to the bottom of the
> issues here, and report back to PSARC-ext with the results. See below:
>
> Cathy Zhou wrote:
>> Garrett D'Amore wrote:
>>> 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.
>
> I don't think this answers the question exactly. While it's true that
> mac clients have to specify that information, the question is whether
> they need to specify it explicitly. For example, could the mere act of
> calling mac_open() be enough to trigger the fast-path to be disabled?
>
Note that IP (a specific dls client) is also a mac client. It also calls
mac_open():
softmac_open()->dld_open()->dls_open_by_dev()->dls_vlan_hold_by_dev()->
dls_mac_hold()-dls_mac_hold()->mac_open()
We cannot tell the difference unless we add a flag in mac_open(). But then,
this is again not transparent to the mac client.
Further, again, as I said, aggregation should be able to work at the same time
when fast-path is used. aggr call mac_open() too.
>>> 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.
>
> Could the mac_open()/mac_close() interaction of the mac client in
> question trigger this rather than the new mac client functions proposed?
>
See above.
Thanks
- Cathy
