Re: Specifying names for tap interfaces

[Darren Reed <darrenr%netbsd.org@localhost>]

On 22/06/2012 9:20 PM, Manuel Bouyer wrote:
> On Fri, Jun 22, 2012 at 02:57:09PM +1000, Darren Reed wrote:
>>>> On 21/06/2012 8:01 PM, Roger Pau Monne wrote:
>>>>> While this is true if you give a name to the interface on the config
>>>>> file, but how can the toolstack (xl, that launches Qemu) choose an
>>>>> interface name and pass it to Qemu when no one is specified? Well,
>>>>> we might be able to search for a free tap device and pass this as the
>>>>> desired name, but this is a really racy solution, as someone else might
>>>>> request a tap device while we are launching Qemu, and take our chosen
>>>>> tap device behind our back, so we will end up failing to create that
>>>>> domain.
>>>>>
>>>>> Also, I don't think there's anyway to create vifs interfaces with a
>>>>> specific name, which I think will also be an interesting feature to
>>>>> have.
>>>>
>>>> So in that second paragraph you've identified the real problem.
>>>
>>> I dissagree that this is the real problem. There is a desired feature:
>>> being able to tag an interface with a user-provided string, and
>>> using this string instead of its name for various task. This is not
>>> restricted to xen xvif or tap devices, I have other use cases too
>>> (on a system with lots of interface, having a meaningfull string
>>> for them would be helpfull). But I don't think remplacing the actual
>>> interface name with a user-specified string is the way to go. This
>>> user-specified string should add information, not replace existing
>>> information.
>>
>> I'm not sure that I follow what you're saying.
>>
>> Can you please expand on that?
> 
> 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.

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.

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?
- how do we get meaning out of the name"wm6"?

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

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.

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.

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

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

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.

Darren