On Thu, Mar 08, 2012 at 03:29:55PM -0800, Pravin Shelar wrote: > On Thu, Mar 8, 2012 at 3:27 PM, Ben Pfaff <[email protected]> wrote: > > On Thu, Mar 08, 2012 at 03:25:16PM -0800, Pravin Shelar wrote: > >> On Thu, Mar 8, 2012 at 3:15 PM, Ben Pfaff <[email protected]> wrote: > >> > On Thu, Mar 08, 2012 at 03:07:41PM -0800, Pravin Shelar wrote: > >> >> On Thu, Mar 8, 2012 at 2:57 PM, Ben Pfaff <[email protected]> wrote: > >> >> > On Thu, Mar 08, 2012 at 07:26:08AM -0800, Pravin B Shelar wrote: > >> >> >> Fixed according to comments from Ben. > >> >> >> v1-v2: > >> >> >> - Added comment for netdev_internal_open > >> >> >> - Removed get-stat call from status check. > >> >> >> > >> >> >> --8<--------------------------cut here-------------------------->8-- > >> >> >> > >> >> >> Netdev-linux calls ETHTOOL_GDRVINFO on every > >> >> >> netdev_linux_get_status() > >> >> >> which is not optimal as drv-info does not change for given device. > >> >> >> So following patch changes netdev_linux_get_status() to read > >> >> >> drv-info at > >> >> >> device initialization and cache it. > >> >> >> > >> >> >> Signed-off-by: Pravin B Shelar <[email protected]> > >> >> > > >> >> > Thanks. > >> >> > > >> >> > This series has a number of patches with the similar purposes of > >> >> > increasing the effectiveness of caching in netdev-linux. They tend to > >> >> > follow the same pattern. But this patch stands out as the only one > >> >> > that populates the cache proactively, before the client asks for it. > >> >> > Why is drvinfo different? That is, if we have to populate drvinfo > >> >> > proactively, why don't we have to populate the other values > >> >> > proactively too? > >> >> > >> >> I didn't do it as we always cache drv-info info. If you want I can add > >> >> caching for error code. > >> > > >> > I mean, this patch obtains the drvinfo as soon as possible, either in > >> > the "open" call (for non-internal netdevs) or as soon as we get an > >> > rtnetlink notification that the device was created (for internal > >> > netdevs). For, say, MTU, we don't do that. Instead, we wait for the > >> > client to ask for the MTU the first time, and then netdev-linux > >> > obtains the MTU and caches it[*]. That seems like a sensible way to > >> > do things; in particular it makes "open" cheap. Is there some reason > >> > that we can do that for MTU but not for drvinfo? > >> > >> I did it for drv-info as it might not be available later when it is > >> asked for; in case device is unregistered. > > > > Why is that true for drvinfo but not for, say, MTU? > as MTU can change and cache will get discarded by dev unregister notification.
Ah. I think I follow now. Thanks, this seems fine. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
