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. -Seb
