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. > [*] Except that if an rtnetlink notification happens to conveniently > show up then we get it from there, as an optimization. But I > doubt that's the common case. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
