[PATCH net] i40e: Prevent unwanted interface name changes

[PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

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")
Signed-off-by: Calvin Owens <calvin@wbinvd.org>
---
 drivers/net/ethernet/intel/i40e/i40e_devlink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_devlink.c b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
index cc4e9e2addb7..40f81e798151 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
@@ -212,6 +212,7 @@ int i40e_devlink_create_port(struct i40e_pf *pf)
 
 	attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
 	attrs.phys.port_number = pf->hw.pf_id;
+	attrs.no_phys_port_name = 1;
 	i40e_devlink_set_switch_id(pf, &attrs.switch_id);
 	devlink_port_attrs_set(&pf->devlink_port, &attrs);
 	err = devlink_port_register(devlink, &pf->devlink_port, pf->hw.pf_id);
-- 
2.47.2

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Michal Schmidt]

On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <calvin@wbinvd.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

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Przemek Kitszel]

On 8/20/25 08:42, Michal Schmidt wrote:
> On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <calvin@wbinvd.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
> 

And, more importantly, noone was complaining on the new name ;)

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

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 <calvin@wbinvd.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
> > 
> 
> 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

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

On Wednesday 08/20 at 09:11 -0700, Calvin Owens wrote:
> 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 <calvin@wbinvd.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
> > > 
> > 
> > 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.

I actually checked, it really goes back that far.

> 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.

I just want to be clear: I'm not here to whine at you all about having
to spend ten minutes fixing some configuration files. My goal is to save
a bunch other people the trouble of doing it over the next five years,
if it's not too late.

If it is true the majority of i40e users have converted, than yes, this
should stay the way it is. I'm *very* skeptical that would be true only
19 months after the release... but I don't have any real data to argue
either way.

> Thanks,
> Calvin

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

On Wednesday 08/20 at 08:42 +0200, Michal Schmidt wrote:
> On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <calvin@wbinvd.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 :)

Should e67a0bc3ed4f be reverted instead? Why is ixgbe special?

Thanks,
Calvin

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

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@wbinvd.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 :)

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 :)

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Przemek Kitszel]

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@wbinvd.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)

> 
> 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

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

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@wbinvd.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?

> > 
> > 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.

If you actually have data on that, obviously that's different. But it
sounds like you're guessing just like I am.

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Przemek Kitszel]

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@wbinvd.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).

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]

> 
>>>
>>> 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

> 
> 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

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

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@wbinvd.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

Re: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted interface name changes

[Paul Menzel]

[Cc: regressions@lists.linux.dev]

TLDR; for the regression folks: This is about a two year old commit 
first appearing in Linux 6.7 (so after the 6.6 LTS series release), part 
of which Red Hat reverted in their distro last year to address the 
userspace regression. Users hit by this might not be able to log into 
their systems due to the network not being configured.


Dear Calvin, dear Przemek,


Thank you for raising this issue.


Am 22.08.25 um 06:23 schrieb Calvin Owens:
> 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@wbinvd.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 :)
>>>>
>>>> Red Hat 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 Red Hat 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.

Too bad Red Hat didn’t report this over a year ago upstream.

>>> 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 :/

I disagree. Debian admins do not upgrade their servers to the newest 
stable release right away to exactly avoid such issues. So I’d argue, as 
with Red Hat, that the change should be reverted as soon as possible, 
before even more users are hit by this.

But, as Przemek is one of the two subsystem maintainers, I guess his 
opinion matters quite a lot.


Kind regards,

Paul

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Jakub Kicinski]

On Thu, 21 Aug 2025 21:23:20 -0700 Calvin Owens wrote:
> > > 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...

Yeah, that's my feeling. Ideally there should be a systemd-networkd
setting that let's user opt out of adding the phys_port_name on
interfaces. 99% of users will not benefit from these, new drivers or
old. We're kinda making everyone suffer for the 1% :(

Re: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted interface name changes

[Jacob Keller]

[-- Attachment #1.1: Type: text/plain, Size: 3060 bytes --]



On 8/22/2025 7:23 AM, Jakub Kicinski wrote:
> On Thu, 21 Aug 2025 21:23:20 -0700 Calvin Owens wrote:
>>>> 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...
> 
> Yeah, that's my feeling. Ideally there should be a systemd-networkd
> setting that let's user opt out of adding the phys_port_name on
> interfaces. 99% of users will not benefit from these, new drivers or
> old. We're kinda making everyone suffer for the 1% :(

There already is, see my thread here:

From
https://lore.kernel.org/netdev/883ee734-b9bd-42be-b072-23640fd34fdb@intel.com/

> If you want to stop including the "np<N>" to the device names, I believe
> you can set the ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0 via udev properties.
> 
> From what I can tell searching online, this can be done by setting an
> appropriate entry in /etc/udev/hwdb.d/ .. i.e. adding this file:
> 
> /etc/udev/hwdb.d/50-net-naming-disable-phys-port-name.hwdb
> net:naming:*
>   ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0
> 
> after adding this file, you also need to update the hardware database with
> 
> $ systemd-hwdb update
> 
> From here, you should be able to reboot and the physical port name would
> be removed from all devices which have it.
> 
> It appears to work on my test system running Fedora with systemd v256.
> 
> At any rate, this is fully an artifact of how systemd renames things and
> I do not believe we should be working around that by modifying our drivers.
> 

I still stand by this, but I can understand the motivations and accept
the changes to allow opting out of physical port names for the older
devices.

> You're unlikely to convince systemd folks to change defaults, but you
> might be able to convince some distributions to change their defaults.
> Either way, you are best to work around this on your system in whichever
> ways you see fit.

I don't know why systemd changed the default, but that change has been
there for sometime. At least a year or two in Fedora if my memory is
accurate. The fact that the default has changed but gone unnoticed
because it is only triggered by a kernel update is I think part of the
challenge.

We can keep applying this workaround to "legacy" devices so that at
least those ones don't get changed randomly when we add devlink
support... but I think the real problem is ultimately outside of our
control in the hands of the systemd and userspace folks who chose to
change the persistent naming scheme default.

Personally, I agree the extra part of the name is useless for my setups,
and I have since configured all my systems to exclude it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

On Friday 08/22 at 07:23 -0700, Jakub Kicinski wrote:
> On Thu, 21 Aug 2025 21:23:20 -0700 Calvin Owens wrote:
> > > > 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...
> 
> Yeah, that's my feeling. Ideally there should be a systemd-networkd
> setting that let's user opt out of adding the phys_port_name on
> interfaces. 99% of users will not benefit from these, new drivers or
> old. We're kinda making everyone suffer for the 1% :(

Thanks Jakub.

I let myself get too worked up about this, I apologize for being such a
pig in this thread. My frustration is not directed at anybody here, I
hope it hasn't come across that way.

RE: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted interface name changes

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Calvin Owens
> Sent: Wednesday, August 20, 2025 6:29 AM
> To: netdev@vger.kernel.org
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Jagielski, Jedrzej
> <jedrzej.jagielski@intel.com>; Vecera, Ivan <ivecera@redhat.com>;
> intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted
> interface name changes
> 
> 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")
> Signed-off-by: Calvin Owens <calvin@wbinvd.org>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_devlink.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> index cc4e9e2addb7..40f81e798151 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> @@ -212,6 +212,7 @@ int i40e_devlink_create_port(struct i40e_pf *pf)
> 
>  	attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
>  	attrs.phys.port_number = pf->hw.pf_id;
> +	attrs.no_phys_port_name = 1;
1 is acceptable, but kernel style prefers true for boolean fields.
Can you use 'true' instead?

>  	i40e_devlink_set_switch_id(pf, &attrs.switch_id);
>  	devlink_port_attrs_set(&pf->devlink_port, &attrs);
>  	err = devlink_port_register(devlink, &pf->devlink_port, pf-
> >hw.pf_id);
Thank you for the patch aligning i40e with ixgbe behavior to prevent unwanted interface renaming. This is correct and minimal.

You're adding attrs.no_phys_port_name = 1; but there's no comment in the function explaining why. While not strictly required, maintainers often expect a short inline comment like:
/* Prevent automatic phys_port_name generation (see ixgbe fix) */

This will help future readers understand why this flag is set, what do you think?

> --
> 2.47.2

Re: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted interface name changes

[Calvin Owens]

On Wednesday 08/20 at 15:51 +0000, Loktionov, Aleksandr wrote:
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Calvin Owens
> > Sent: Wednesday, August 20, 2025 6:29 AM
> > To: netdev@vger.kernel.org
> > Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> > Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> > Abeni <pabeni@redhat.com>; Jagielski, Jedrzej
> > <jedrzej.jagielski@intel.com>; Vecera, Ivan <ivecera@redhat.com>;
> > intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted
> > interface name changes
> > 
> > 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")
> > Signed-off-by: Calvin Owens <calvin@wbinvd.org>
> > ---
> >  drivers/net/ethernet/intel/i40e/i40e_devlink.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> > b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> > index cc4e9e2addb7..40f81e798151 100644
> > --- a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> > +++ b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> > @@ -212,6 +212,7 @@ int i40e_devlink_create_port(struct i40e_pf *pf)
> > 
> >  	attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
> >  	attrs.phys.port_number = pf->hw.pf_id;
> > +	attrs.no_phys_port_name = 1;
> 1 is acceptable, but kernel style prefers true for boolean fields.
> Can you use 'true' instead?

Sure, if this ends up going forward I'll do that in v2.

> >  	i40e_devlink_set_switch_id(pf, &attrs.switch_id);
> >  	devlink_port_attrs_set(&pf->devlink_port, &attrs);
> >  	err = devlink_port_register(devlink, &pf->devlink_port, pf-
> > >hw.pf_id);
> Thank you for the patch aligning i40e with ixgbe behavior to prevent unwanted interface renaming. This is correct and minimal.
> 
> You're adding attrs.no_phys_port_name = 1; but there's no comment in the function explaining why. While not strictly required, maintainers often expect a short inline comment like:
> /* Prevent automatic phys_port_name generation (see ixgbe fix) */
> 
> This will help future readers understand why this flag is set, what do you think?

Hmm, it feels a bit redundant to me: "no_phys_port_name" is already
pretty descriptive, and the details (with SHAs) are one git-blame away
in the commit message.

> > --
> > 2.47.2
> 

Re: [Intel-wired-lan] [PATCH net] i40e: Prevent unwanted interface name changes

[Paul Menzel]

Dear Calvin,


Thank you for your patch..

Am 20.08.25 um 06:29 schrieb Calvin Owens:
> 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")
> Signed-off-by: Calvin Owens <calvin@wbinvd.org>
> ---
>   drivers/net/ethernet/intel/i40e/i40e_devlink.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_devlink.c b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> index cc4e9e2addb7..40f81e798151 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_devlink.c
> @@ -212,6 +212,7 @@ int i40e_devlink_create_port(struct i40e_pf *pf)
>   
>   	attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
>   	attrs.phys.port_number = pf->hw.pf_id;
> +	attrs.no_phys_port_name = 1;
>   	i40e_devlink_set_switch_id(pf, &attrs.switch_id);
>   	devlink_port_attrs_set(&pf->devlink_port, &attrs);
>   	err = devlink_port_register(devlink, &pf->devlink_port, pf->hw.pf_id);

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul