Message-ID: <aKfwuFXnvOzWx5De@mozart.vkv.me>
Date: Thu, 21 Aug 2025 21:23:20 -0700
From: Calvin Owens <calvin@...nvd.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Michal Schmidt <mschmidt@...hat.com>, netdev@...r.kernel.org,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jedrzej Jagielski <jedrzej.jagielski@...el.com>,
	Ivan Vecera <ivecera@...hat.com>, intel-wired-lan@...ts.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] i40e: Prevent unwanted interface name changes

On Thursday 08/21 at 22:39 +0200, Przemek Kitszel wrote:
> On 8/21/25 16:23, Calvin Owens wrote:
> > On Thursday 08/21 at 10:00 +0200, Przemek Kitszel wrote:
> > > On 8/20/25 19:41, Calvin Owens wrote:
> > > > On Wednesday 08/20 at 08:31 -0700, Calvin Owens wrote:
> > > > > On Wednesday 08/20 at 08:42 +0200, Michal Schmidt wrote:
> > > > > > On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <calvin@...nvd.org> 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
> > > > > 
> > > > > Well, I was relying on the new ixgbe names, and I had to revert them
> > > > > all in a bunch of configs yesterday after e67a0bc3ed4f :)
> > > 
> > > we have fixed (changed to old naming scheme) ixgbe right after the
> > > kernel was used by real users (modulo usual delay needed to invent
> > > a good solution)
> > 
> > No, the "fix" actually broke me for a *second time*, because I'd
> > already converted my infrastructure to use the *new* names, which match
> > i40e and the rest of the world.
> > 
> > We've seen *two* user ABI regressions in the last several months in
> > ixgbe now, both of which completely broke networking on the system.
> > 
> > I'm not here to whine about that: I just want to save as many people out
> > there in the real world as I can the trouble of having to do the same
> > work (which has absolutely no benefit) over the next five years in i40e.
> > 
> > If it's acceptable to break me for a second time to "fix" this, because
> > I'm the minority of users (a viewpoint I am in agreement with), it
> > should also be acceptable to break the minority of i40e users who are
> > running newer kernels to "fix" it there too.
> > 
> > Why isn't it?
> 
> I think we agree that it is ok-ish to sometime break setups for bleeding
> edge users, then fix (aka undo). It's bad that this time it was with
> effect equivalent to the first breakage (hope that it was easier to fix
> locally when it occurred second time in a row).

I just want to re-emphasize, it was *not* my intent to gripe at you
about this. A big reason I test new kernels is in the hope I can hit
things like this myself and get them fixed before they impact the wide
userbase, I'm only frustrated I'm probably too late here to do that.

> But we dispute over change from Oct 2023, for me it is carved in stone
> at this point. Every user either adjusted or worked it around [1]

IMHO the date of the release (Jan 2024) is more relevant than the
commit date, but it's not really that different in this case.

I think there's merit to the idea that the lack of complaining is a sign
that most users have not had to adjust yet, because if they had, they'd
have complained about it. But I don't have any real data either way.

The objections raised over the new interface naming in ixgbe are in no
way specific to ixgbe. You can s/ixgbe/i40e/ any mail about it and
nothing really changes. They're generalized objections against the
renaming of interfaces, so from a certain POV people *are* actively
complaining.

> > > > And, even if it is e67a0bc3ed4f that introduced it, v6.7 was the first
> > > > release with it. I strongly suspect most servers with i40e NICs running
> > > > in the wild are running older kernels than that, and have not yet
> > > > encountered the naming regression. But you probably have much better
> > > > data about that than I do :)
> > > 
> > > RedHat patches their kernels with current code of the drivers that their
> > > customers use (including i40e and ixgbe)
> > > One could expect that changes made today to those will reach RHEL 10.3,
> > > even if it would be named "kernel 6.12".
> > > 
> > > (*) the changes will likely be also in 10.2, but I don't want to make
> > > any promises from Intel or Redhat here
> > 
> > But how many i40e users are actually on the most recent version of RHEL?
> > Not very many, is my guess. RHEL9 is 5.14, and has the old behavior.
> 
> RHEL 9 backported devlink for i40e in July 2024 [0], together with undo
> of interface name change [1] (this likely tells why there were zero
> complains from RH users).
> 
> [0]
> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/commit/bcbc349375ecd977aa429c3eff4d182b74dcdd8a
> 
> [1]
> https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/commit/5ab8aa31dc2b44fbd6761bb19463f5427b9be245

Heh. Thank you very much for checking that, and for the links.

> > 
> > If you actually have data on that, obviously that's different. But it
> > sounds like you're guessing just like I am.
> 
> I could only guess about other OS Vendors, one could check it also
> for Ubuntu in their public git, but I don't think we need more data, as
> ultimate judge here are Stable Maintainers

Maybe I'm barking up the wrong tree, it's udev after all that decides to
read the thing in /sys and name the interfaces differently because it's
there...

In any case, Debian stable is on 6.12 and didn't patch it (just
checked), so I concede, it is simply too late :/

Thanks,
Calvin

Powered by blists - more mailing lists