Sebastien Roy wrote:
> Cathy Zhou wrote:
>> Sebastien Roy wrote:
>>> 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()
>
> I knew that, but I had forgotten that there is a mac_open() for every
> dld_open(). It used to be that dls_vlan_hold() would only call
> mac_open() once. You're right, that this means that mac_open() as-is
> can't be used as the sole differentiator.
>
> As it is, you don't know at mac_open() time if the client is IP or
> something else. That doesn't happen until a DL_BIND_REQ is issued.
>
> Garrett and Erik, do you now understand the design constraint? Do you
> see an alternative? I'm personally satisfied with the architecture
> given Cathy's explanation. Can you confirm either way so that we can
> make forward progress?
>
>> We cannot tell the difference unless we add a flag in mac_open(). But
>> then, this is again not transparent to the mac client.
>
> It would be transparent if the flag said, "I'm IP", but it wouldn't
> work since you don't know at mac_open() time what the mac client is
> going to be bound to.
>
>> 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.
>
> Maybe I'm missing something, but as far as I know, aggregations can't
> work with IP interfaces also plumbed, fast-path or no fast-path.
> They're both active mac clients. mac_open() should just plain fail
> with EBUSY for aggregations regardless.
>
> In any case, that's moot since I now understand why mac_open() can't
> be used to enable or disable the fast-path.
Hmmm... maybe IP needs a variant of mac_open(), or some other way to
differentiate it.
My biggest concern is still that have certain clients that have to
explicitly disable fast path, but only for legacy NICs. I'm not quite
ready to throw in the towel on this one.
Is there not some way that we could do something special for IP (the
main fast path consumer, I believe) apart from other mac clients?
Maybe its not worth worrying about, seeing as this API is private
anyway. But I *really* *REALLY* hope that it will just plain go away
before the MAC API is published. I have little real hope of that
though, so I'd prefer to see effort expended now to make at least the
public API boundaries fast-path (and clearview!) agnostic.
-- Garrett
