On Thu, 27 Jun 2019 10:48:08 -0700 Jakub Kicinski <jakub.kicin...@netronome.com> wrote:
> On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote: > > Hi all. > > > > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for > > netdevice name length. Now when we have PF and VF representors > > with port names like "pfXvfY", it became quite common to hit this limit: > > 0123456789012345 > > enp131s0f1npf0vf6 > > enp131s0f1npf0vf22 > > > > Since IFLA_NAME is just a string, I though it might be possible to use > > it to carry longer names as it is. However, the userspace tools, like > > iproute2, are doing checks before print out. So for example in output of > > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is > > completely avoided. > > > > So here is a proposal that might work: > > 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than > > IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel, > > user should be prepared for any string size. > > 2) Add a file in sysfs that would indicate that NAME_EXT is supported by > > the kernel. > > 3) Udev is going to look for the sysfs indication file. In case when > > kernel supports long names, it will do rename to longer name, setting > > IFLA_NAME_EXT. If not, it does what it does now - fail. > > 4) There are two cases that can happen during rename: > > A) The name is shorter than IFNAMSIZ > > -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string: > > original IFLA_NAME = eth0 > > original IFLA_NAME_EXT = eth0 > > renamed IFLA_NAME = enp5s0f1npf0vf1 > > renamed IFLA_NAME_EXT = enp5s0f1npf0vf1 > > B) The name is longer tha IFNAMSIZ > > -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would > > contain the new one: > > original IFLA_NAME = eth0 > > original IFLA_NAME_EXT = eth0 > > renamed IFLA_NAME = eth0 > > renamed IFLA_NAME_EXT = enp131s0f1npf0vf22 > > I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl, > right? And maybe there is some crazy application out there which > mixes netlink and ioctl. > > I guess it's not worse than status quo, given that today renames > will fail and we will either get truncated names or eth0s.. > > > This would allow the old tools to work with "eth0" and the new > > tools would work with "enp131s0f1npf0vf22". In sysfs, there would > > be symlink from one name to another. > > > > Also, there might be a warning added to kernel if someone works > > with IFLA_NAME that the userspace tool should be upgraded. > > > > Eventually, only IFLA_NAME_EXT is going to be used by everyone. > > > > I'm aware there are other places where similar new attribute > > would have to be introduced too (ip rule for example). > > I'm not saying this is a simple work. > > > > Question is what to do with the ioctl api (get ifindex etc). I would > > probably leave it as is and push tools to use rtnetlink instead. > > > > Any ideas why this would not work? Any ideas how to solve this > > differently? > > Since we'd have to update all user space to make use of the new names > I'd be tempted to move to a more structured device identification. > > 5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ... > > vs: > > 5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ... > > * ;) > > And allow filtering/selection of device based on more attributes than > just name and ifindex. In practice in container workloads, for example, > the names are already very much insufficient to identify the device. > Refocusing on attributes is probably a big effort and not that practical > for traditional CLI users? IDK > > Anyway, IMHO your scheme is strictly better than status quo. Or Cisco style naming ;-) Ethernet0/0 There is a better solution for human use already. the field ifalias allows arbitrary values and hooked into SNMP. Why not have userspace fill in this field with something by default?
