netdev - RE: [RFC net-next v1 1/1] e1000e: Introduce private flag and module param to disable K1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO1PR11MB5089BDD57F90FE7BEBE824F5D654A@CO1PR11MB5089.namprd11.prod.outlook.com>
Date: Mon, 14 Jul 2025 21:30:53 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: Simon Horman <horms@...nel.org>, "Lifshits, Vitaly"
	<vitaly.lifshits@...el.com>
CC: "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Ruinskiy, Dima"
	<dima.ruinskiy@...el.com>, "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>
Subject: RE: [RFC net-next v1 1/1] e1000e: Introduce private flag and module
 param to disable K1



> -----Original Message-----
> From: Simon Horman <horms@...nel.org>
> Sent: Monday, July 14, 2025 9:55 AM
> To: Lifshits, Vitaly <vitaly.lifshits@...el.com>
> Cc: andrew+netdev@...n.ch; davem@...emloft.net; edumazet@...gle.com;
> kuba@...nel.org; pabeni@...hat.com; netdev@...r.kernel.org; Ruinskiy, Dima
> <dima.ruinskiy@...el.com>; Nguyen, Anthony L <anthony.l.nguyen@...el.com>;
> Keller, Jacob E <jacob.e.keller@...el.com>
> Subject: Re: [RFC net-next v1 1/1] e1000e: Introduce private flag and module
> param to disable K1
> 
> On Thu, Jul 10, 2025 at 12:24:55PM +0300, Vitaly Lifshits wrote:
> > The K1 state reduces power consumption on ICH family network controllers
> > during idle periods, similarly to L1 state on PCI Express NICs. Therefore,
> > it is recommended and enabled by default.
> > However, on some systems it has been observed to have adverse side
> > effects, such as packet loss. It has been established through debug that
> > the problem may be due to firmware misconfiguration of specific systems,
> > interoperability with certain link partners, or marginal electrical
> > conditions of specific units.
> >
> > These problems typically cannot be fixed in the field, and generic
> > workarounds to resolve the side effects on all systems, while keeping K1
> > enabled, were found infeasible.
> > Therefore, add the option for system administrators to globally disable
> > K1 idle state on the adapter.
> >
> > Link: https://lore.kernel.org/intel-wired-
> lan/CAMqyJG3LVqfgqMcTxeaPur_Jq0oQH7GgdxRuVtRX_6TTH2mX5Q@...l.gmail.
> com/
> > Link: https://lore.kernel.org/intel-wired-
> lan/20250626153544.1853d106@...x.my.domain/
> > Link: https://lore.kernel.org/intel-wired-lan/Z_z9EjcKtwHCQcZR@mail-itl/
> >
> > Signed-off-by: Vitaly Lifshits <vitaly.lifshits@...el.com>
> 
> Hi Vitaly,
> 
> If I understand things correctly, this patch adds a new module parameter
> to the e1000 driver. As adding new module parameters to networking driver
> is discouraged I'd like to ask if another mechanism can be found.
> E.g. devlink.

One motivation for the module parameter is that it is simple to set it "permanently" by setting the module parameter to be loaded by default. I don't think any distro has something equivalent for devlink or ethtool flags. Of course that’s not really the kernel's fault.

I agree that new module parameters are generally discouraged from being added. A devlink parameter could work, but it does require administrator to script setting the parameter at boot on affected systems. This also will require a bit more work to implement because the e1000e driver does not expose devlink.

Would an ethtool private flag on its own be sufficient/accepted..? I know those are also generally discouraged because of past attempts to avoid implementing generic interfaces.. However I don't think there is a "generic" interface for this, at least based on my understanding. It appears to be a low power state for the embedded device on a platform, which is quite specific to this device and hardware design ☹