Re: Specifying names for tap interfaces

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Jun 22, 2012 at 10:13:30PM +1000, Darren Reed wrote:
> > Right now, the unique identifier of an interface is its name, which is
> > set by the system when the interface is discovered. I don't think we should
> > change this part, because we are used to the names as they are now, and it
> > also carry some information (wm0 is an intel adapter, tap0 is a pseudo
> > interface, xvif5-0 is a Xen PV backend interface connected to the interface
> > of index 0 in the guest id 5, etc).
> 
> The naming of interfaces is dependent on the driver, not the user.

Yes. I don't see this as a problem.

> 
> It currently conveys some information but the real information is
> only available in the kernel probing output from when the system
> boots.
> 
> Personally, I find the "tap" naming for pseudo interfaces obscure
> because a "network tap" is traditionally something that is used for
> sniffing and that's not NetBSD uses them for. But I digress.
> 
> The point here is that the driver based interface name conveys some
> coded information that is meaningful to people that know which drivers
> use which abbreviations and that's it. That is unless there is some
> magical way in which random people equate "wm" with "Intel" (yes I know,
> "man wm".) But note that the user or administrator never gets any choice
> in whether it is "fxp0" or "wm0", it's decided by programmers that
> write the drivers.

But precisely, 'man wm' is usefull, and a way to associate an interface
name with its driver name is a must have. Actually this is done with
the name. If we allow the name to change at runtime, there has to be
a way to find this information (other than "dmesg |grep name", precisely
because name can change).


> To me this screams out for better management of network interfaces.
> Something that allows the strings output at bootup to be reported
> via the CLI, perhaps including how it is attached (but maybe that
> is going just a bit too far.)
> 
> > But sometimes we'd like to have more, user-defined information easily
> > available for interfaces, on systems with lots of interfaces.
> 
> Definitely.
> 
> > example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
> > domU 5 ? I have to use xm list to match the id against a domU's name.
> > example 2: I have a system with 2 quad-port intel. I know wm6 is
> > the third port of the second quad-port adapter, but what is it connected to 
> > ?
> 
> There's two of issues here that we can address:
> - why can't xvif5-0 be a more meaningful name?

Because the kernel (which creates the interface) doesn't have easy access to
this information.

> - how do we get meaning out of the name"wm6"?

what we get is "this is the 6th instance of the wm driver". We need this
information too.

> 
> > With xaliases (which could also be called label, this is probably the righ
> > name for that), users could add some informations to interfaces
> > (either by hand or by some script). 
> > In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
> > label xvif5-0 with the domU's name followed by interface index in the domU
> > (say, if by domU's name is proxy, the label would be proxy0).
> > In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
> > course):
> > label team-foo-vlan
> 
> Wouldn't it be better to dispense with the "xvif5-0" altogether
> and just have "proxy0" as the interface name with nothing else?
> 
> Do I really need to know that proxy0 is a xvif5-0 when I do
> check to see which IP addresses are associated with it, etc?
> Do I even care?

I want to know it's a xvif, at last. Now, proxy0 could be the name and
xvif is another data in ifconfig's output, but this information is needed.
And (sadly) proxy0 can't be created with this name, it has to be changed
later by the configure script.

> 
> The point here is that proxy0 might be xvif1-0 or xvif5-0,
> depending on the order in which that domU is started relative
> to the other domU's.

Yes, of course. And if you reboot the domU, it'll be something else.
And, in kernel, you'll have a proxy0 with a different struct ifp.

> 
> In the very least, the way in which network interfaces are created
> for Xen is rather primitive as the creation of the domU should be
> when the interface is dynamically created and named rather than
> depend on a static naming approach.

I don't understand what you mean here.

> 
> > Then, ifconfig would display the label as part of interface data,
> > which can give the information to the admin.
> >
> > In addition, if we make sure labels are unique in a system, we
> > could refer to interfaces by label instead of by name (just like
> > I'd like to use a GPT label in fstab instead of /dev/dkX), we could
> > use labels in places where names are actually used. If we make the kernel
> > know that label:X in ifreq is interface's label X and not interface's
> > name label:X, modifications to network tools should be minimal.
> 
> What you're depending on here is the fact that all of the
> existing interface names are much shorter than IFNAMSIZ.
> That plus the user string being short. The current value
> of IFNAMSIZ is 16. So the above string...
> 
> team-foo-vlan:tap0
> 
> is already too long. So in addition to adding the label string
> structure, increasing IF_NAMESIZE (probably double it) is also
> required. That might bear some extra thinking about.

You're right, 16 is not enough. But with the rename approach, it's not enough
either (plus, you probably want to keep short name for netstat and other
outputs, while the admin may want to use long name to describe what the
interface is).

> 
> On top of that, you'll probably find various parsers will treat
> the above string as not being an interface name as colons are
> often used to separate parameters.

another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

> 
> Another problem that I see with this is that "team-foo-vlan" is
> redundant information. Knowing "tap0" is enough to uniquely
> identify the network interface, so why would I want to also
> use the label? Similarly, if I know that "team-foo-vlan" but
> I can't remember which tap interface number, why should I need
> to know it?

I think you're mixing both here. In my proposal we can refer to an
interface (reusing you example) as:
tap0
(this is the name) or
label:team-foo-vlan
(this uses the label - the prefix label: is there to instruct the parser
that we're using a label and not a name). You won't use
team-foo-vlan:tap0 because this is, indeed, useless.

> 
> What this really points toward is we need to support being able
> to rename "tap0" to "team-foo-vlan0" and for there to be some
> way to identify what "team-foo-vlan0" is (for those that care.)
> The means for doing that might also enable more information to
> be displayed about things like "wm0" and "lo0" than are typically
> easily available today.

Yes, that may work too. But I fear some people will want to use a string
that is persistant (at last until the system is rebooted) to refer
to interface, not something that can be changed ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--