Thu, Jun 27, 2019 at 07:14:31PM CEST, dsah...@gmail.com wrote: >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.
There are more usecases for this, yes. > >> >> 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. Sure, udev can query rtnetlink. I just proposed it as an option, anyway, it's implementation detail. > > >> 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? Yes. However, updated tools (which would be eventually all) are going to show only the ext one. > >> >> 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. Please note that this /sys/class/net/ifacename dirs are already created. What I propose is to have symlink from ext to the short name or vice versa. The solution really does not "rely" on this... > >> >> 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. Spam? warn_once? > >> >> 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. I don't see other way though, do you? The ioctl names are unextendable :/
