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