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