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?
[*] 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
