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

YAMAMOTO Takashi yamamoto at valinux.co.jp
Fri Feb 1 01:53:10 UTC 2013


> 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.

>         * 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.

> 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?

> 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?)


> (OVS-created tap devices are distinct from tap devices created other
> ways, which at least on Linux can be added to an OVS bridge in the usual
> way and don't require any special support.  Thus, removing this feature
> would not keep OVS from working with tap devices.)
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

More information about the dev mailing list