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 <y...@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 <yamam...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
