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? _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
