On Wednesday 08/20 at 11:41 +0200, Przemek Kitszel wrote:
> On 8/20/25 08:42, Michal Schmidt wrote:
> > On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <[email protected]> wrote:
> > > The same naming regression which was reported in ixgbe and fixed in
> > > commit e67a0bc3ed4f ("ixgbe: prevent from unwanted interface name
> > > changes") still exists in i40e.
> > >
> > > Fix i40e by setting the same flag, added in commit c5ec7f49b480
> > > ("devlink: let driver opt out of automatic phys_port_name generation").
> > >
> > > Fixes: 9e479d64dc58 ("i40e: Add initial devlink support")
> >
> > But this one's almost two years old. By now, there may be more users
> > relying on the new name than on the old one.
> > Michal
> >
>
> And, more importantly, noone was complaining on the new name ;)
I'm just guessing with the Fixes tag, I didn't actually go back and try
to figure out when it broke. Let me double check, it would certainly
make more sense if it broke more recently.
But there are a lot of reasons I still think it should be fixed:
1) I have ixgbe and i40e cards in one machine, the mis-match
between the interface naming pattern is irritating. Can't we
at least be consistent within the same manufacturer?
2) The new names have zero real value: "enp2s0fX" vs
"enp2s0fXnpX", the "npX" prefix is entirely redundant for
this i40e card. Is there some case where it can have meaning?
I apologize if I'm glossing over something here, but it looks
entirely pointless. If it solved some real problem, I'd be a
lot more amenable to it.
3) It's a userspace ABI regression which causes previously
working servers to be unable to connect to the network after
a simple kernel upgrade.
And, at the end of the day, it *is* a userspace ABI regression. If it
matters enough in ixgbe to warrant a *second* userspace ABI regression
to fix it, I think it warrants that in i40e too.
Thanks,
Calvin
