[ovs-dev] [PATCH 14/18] keep "kernel name" for each netdev

Ben Pfaff blp at nicira.com
Fri Feb 1 02:56:31 UTC 2013


On Fri, Feb 01, 2013 at 10:53:10AM +0900, YAMAMOTO Takashi wrote:
> > On Thu, Jan 31, 2013 at 07:49:48PM +0900, YAMAMOTO Takashi wrote:
> >> From: YAMAMOTO Takashi <yamt at mwd.biglobe.ne.jp>
> >> 
> >> where interface renaming is not supported (NetBSD), remember both of
> >> our netdev name and the correspoinding kernel name separately.
> >> the latter is necessary to talk with kernel using interface names.
> >> eg. ifioctls, bpf
> >> 
> >> XXX there should be a proper way to query kernel name.
> >> 
> >> Signed-off-by: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
> > 
> > So is the issue here that on NetBSD one cannot specify the name for a
> > new tap device?  The kernel always assigns its own name?  Then there
> > might be an extra problem.  Consider this case:
> 
> yes.  kernel picks a name (eg. tap1) and a user can't changed it.

OK.

> > 
> >         * ovs-vswitchd starts up and creates some tap devices.  It knows
> >           the mapping between the user-requested name and the kernel
> >           name.
> > 
> >         * Admin restarts ovs-vswitchd.
> > 
> >         * New instance of ovs-vswitchd creates new tap devices because
> >           it does not know the kernel names of the existing ones and
> >           does not have a way to discover them.  The existing ones are
> >           effectively leaked.
> 
> there isn't a leak as ovs-vswitchd destroys the old one when stopping.

OK.  But this may cause a different inconvenience to the user: if the
user configured an IP address on the tap device, then restarting
ovs-vswitchd will drop that IP address and the user will have to add it
back.  This doesn't happen with the Linux kernel datapath, and I don't
think it happens with the Linux userspace datapath (I can't say for the
FreeBSD one).  But if that issue does not bother you, then I will not
worry about it.

> > 
> > Furthermore, it seems likely that the tap devices created this way will
> > not actually be useful to the user, because the user does not have any
> > way, either, to discover the mapping between his names and the kernel
> > names.  Thus, the user doesn't know how to use the kernel tap devices.
> 
> right.  it's what XXX in the commit log says.
> 
> it would be useful if the user can query the corresponding kernel name
> using one of ovs-xxxctl.  having a way to query netdev implementation
> specific data in general might be useful.  any idea?

A command accessible via ovs-appctl would be the easiest way, I guess.
If you look for calls to unixctl_command_register(), then you can see
some examples.

> > I am not sure that OVS-created tap devices are that useful anyway.  I've
> > thought for some time of removing them from OVS entirely.  But it seems
> > that they are likely to be even less useful on netbsd.  Should we simply
> > not support them there?
> 
> it would be good to have a way to create a bridge without a local port.
> (is there any?)

There is currently no way.  There is a significant amount of code that
assumes every bridge has a local port, so it might be difficult to
change this.



More information about the dev mailing list