On 6/27/19 3:43 AM, 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
QinQ (stacked vlans) is another example. > > 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. no sysfs files. Johannes added infrastructure to retrieve the policy. That is a more flexible and robust option for determining what the kernel supports. > 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 so kernel side there will be 2 names for the same net_device? > > 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. I would prefer a solution that does not rely on sysfs hooks. > > Also, there might be a warning added to kernel if someone works > with IFLA_NAME that the userspace tool should be upgraded. that seems like spam and confusion for the first few years of a new api. > > 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. The ioctl API is going to be a limiter here. ifconfig is still quite prevalent and net-snmp still uses ioctl (as just 2 common examples). snmp showing one set of names and rtnetlink s/w showing another is going to be really confusing.