[systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Jordan Hargrave schreef op 13-04-16 01:24:

> I am the primary developer of biosdevname.  I've been wanting this
> naming functionality built into systemd or even the OS itself.
> Primarily I am interested in servers with multiple physical and
> virtual NICs but getting it working on desktops would be a bonus as
> well.
> 
> The problem lies in the mapping itself.  Network devices can be on a
> single, dual, or even quad-port cards.  Each one of these ports can be
> 'virtualized' through SR-IOV or NIC partitioning, one physical card
> can potentially have hundreds of virtual NICs.  Other cards implement
> multiple network interfaces for a single PCI bus:dev:func pair.
> SMBIOS table has a mapping from slot number to PCI device, this can be
> used to determine the physical slot number of a network card (and its
> ports).
> 
> So there are at least 4 variables that you must keep track of, for add-in cards
> 
> PCI slot #
> NIC physical port # (for multi-port cards)
> NIC device ID (Each physical port can implement multiple network
> devices)  see mlx4 driver or i.
> NIC partition number (each device can then have multiple
> partitions/virtual devices)  See. SR-IOV or Dell NPAR (network
> partitioning)
> 
> For embedded devices (onboard), PCI slot # is replaced by instance
> number.  This is also available through SMBIOS.

Given this technology and virtualisation possibilities for larger
systems it seems unwanted, unnecessary and improbably that you would
ever want a simple "works for everyone scheme".

Any complex system that actually uses all of these features might even
have 100s of "nics". If you need to be able to address all of these
devices by a simple name, it becomes clear you need something structured
and deterministic.

Anything else would probably not make sense for the usage scenario you'd
start to envision.

I take it, such a usage scenario could for instance this being a host
system for a hypervisor that distributes all of these individual nics to
its guests (for instance, I don't know).

I cannot really imagine any other system where you'd need that. But
again, aside.

* Do you feel pure-name addressing is the way this should be done? You
are basically encoding an address in a name. The software that sets up
or uses this name is going to know about the scheme or it couldn't do
anything with it. To this system, these names are not going to be "black
boxes", their generation and usage might see code constructing them or
deconstructing them to know about its elements.

What you get is something like a sequence of arrays (multi-dimensional
array) but instead of addressing [0][2][4] you are going to be doing
name-p0p2p4 using an encoded address.

At that point you wonder whether you do not want the system to enable
direct addressing of the components using a filesystem path (for
instance) such as not "/sys/class/net/enp3s0" but rather
"/sys/class/net/en/3/0" as a manner of speaking.

So my first question and consideration is: from your point of view, do
these names suffice for you, or do you require more direct addressing of
the components?



Then the second question is: can you imagine a need for people to map
any of these names or components to well-understood "aliases" such as
eth0 or ethernet0?

Ideally speaking, if you set up a system of ports and virtualized ports
and so on, the direct path to the root device (of such) would not be
very relevant to you, as long as you can access that root device
directly (e.g. through an alias).

As such, this /net/en/3/0 as a root "address" might not be as meaningful
to you as what would come beneath it.

In other words, the subtree you have "designed" for your particular
system becomes more important to you than the place where that subtree
is "mounted" as long as you know where.

The actual physical hardware address of your "root device" is not going
to be as important as being able to address it reliably in the first
place. The fact that it is going to be /net/3/0 or /net/4/0 is not going
to be relevant to you.

Moreoever, if you want your system to be portable, you would want it to
be independent in some way of these "hardcoded" hardware addresses.

You might have a system image or an entire suit of configuration tools,
that is already constructed towards generating this system you want.

Where your root device is going to be in this particular system, is not
that important. However, while setting up, you will need to know this
address and use it as the "anchor".

This form of anchoring could equally well be done by using an alias.

So considering that I'm actually proposing (or have been thinking about)
keeping this "internal subdivision" intact while making the addressing
of the root device a system-independent thing, you could for instance
think that:

"ethernet0" does not indicate a final port an sich, it would indicate a
root ethernet device.

If this device had 4 ports, they would then not be "ethernet0"
"ethernet1" and so on, but you would collect them using "ethernet0-1" or
whatever scheme you would use.

For an encoded system where user exposure is not important, "ethernet"
might indeed be too long of a name.

STILL I feel that aliasing the "real hardware address" to something that
is meaningful to a user (or administrator) would not be an odd thing to
do at all.

Perhaps you may think of the current writing I have been doing here as a
way to "automatically alias" the "root ethernet devices" the system
finds /on each boot/ in a predictable way given a limited number of
sources (embedded, cards) such that they become meaningful to a user.

Meaning: the way most people start counting or numbering at 1.

We count from one, but index from zero. Indexes in general are not
meaningful to people, but logically the first addresses (increments)
starting from a memory location are simply 0, 1, 2, etc.

So we use 0, 1, 2 as a form of addressing, while we use 1, 2, 3 as a
form of "naming". These numbers are names. Some people start network
segment numbering at 0. I like to start at 1. 192.168.1.1 feels better
to me than 192.168.0.1, because "0" is not my "first" network, "1" is.
There is no need to use "0" here because it is not really an index. It
is a name.

There is not really going to be any amount of memory allocation or
whatever that is going to change because you start at 1 and not at 0.

Even if you start at 253, nothing will happen.

The "enp3s0" is an address, it is not really a name. People like to give
names to things. Whatever internal subdivision you might have does not
usually need names.

We give names to streets but not to houses. We number houses, and
although they are not really indexes they do sort of work that way, and
they start usually at 1 because they are still like names a little bit.

TL;DR: I want to ask whether you feel there is any valid reason for me
to be proposing here that an actual address-to-name aliasing takes place
here.

What I have been proposing is not necessarily to do away with the
addresses. Certainly I have not been proposing to kill the internal
subdivision you describe.

What I have been proposing is to at least add an alias to the root
devices that can be used in lieu of the address.

If I have a single NIC, I may want it to be ethernet0.

If I have a single device that has 2 ports, I may want it to
automatically become not ethernet0 and 1, but ethernet0-1 and ethernet0-2.

At that point the naming becomes too verbose already, actually.

So you'd really be back at "eth0-1" and "eth0-2" (which is not really
possible).

I would really appreciate a system where you'd have some level of
control over these aliases. But that /having/ aliases would not be
solely dependent on the user (that may not know how to do it).

And you could also imagine a situation where these aliases were
available but that if someone wanted to use the direct hardware address,
that would still be possible.