netdev - RE: [PATCH net-next,v3,2/2] i40e: support generic devlink param "max_mac_per

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <IA3PR11MB89862C0CB04BF30C66C7333CE500A@IA3PR11MB8986.namprd11.prod.outlook.com>
Date: Thu, 4 Sep 2025 06:04:22 +0000
From: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>
To: "mheib@...hat.com" <mheib@...hat.com>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>
CC: "przemyslawx.patynowski@...el.com" <przemyslawx.patynowski@...el.com>,
	"jiri@...nulli.us" <jiri@...nulli.us>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "horms@...nel.org" <horms@...nel.org>, "Keller,
 Jacob E" <jacob.e.keller@...el.com>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>
Subject: RE: [PATCH net-next,v3,2/2] i40e: support generic devlink param
 "max_mac_per_vf"



> -----Original Message-----
> From: mheib@...hat.com <mheib@...hat.com>
> Sent: Wednesday, September 3, 2025 11:43 PM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: przemyslawx.patynowski@...el.com; jiri@...nulli.us;
> netdev@...r.kernel.org; horms@...nel.org; Keller, Jacob E
> <jacob.e.keller@...el.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>; Mohammad Heib <mheib@...hat.com>
> Subject: [PATCH net-next,v3,2/2] i40e: support generic devlink param
> "max_mac_per_vf"
> 
> From: Mohammad Heib <mheib@...hat.com>
> 
> Currently the i40e driver enforces its own internally calculated per-
> VF MAC filter limit, derived from the number of allocated VFs and
> available hardware resources. This limit is not configurable by the
> administrator, which makes it difficult to control how many MAC
> addresses each VF may use.
> 
> This patch adds support for the new generic devlink runtime parameter
> "max_mac_per_vf" which provides administrators with a way to cap the
> number of MAC addresses a VF can use:
> 
> - When the parameter is set to 0 (default), the driver continues to
> use
>   its internally calculated limit.
> 
> - When set to a non-zero value, the driver applies this value as a
> strict
>   cap for VFs, overriding the internal calculation.
> 
> Important notes:
> 
> - The configured value is a theoretical maximum. Hardware limits may
>   still prevent additional MAC addresses from being added, even if the
>   parameter allows it.
> 
> - Since MAC filters are a shared hardware resource across all VFs,
>   setting a high value may cause resource contention and starve other
>   VFs.
> 
> - This change gives administrators predictable and flexible control
> over
>   VF resource allocation, while still respecting hardware limitations.
> 
> - Previous discussion about this change:
>   https://lore.kernel.org/netdev/20250805134042.2604897-2-
> dhill@...hat.com
>   https://lore.kernel.org/netdev/20250823094952.182181-1-
> mheib@...hat.com
> 
> Signed-off-by: Mohammad Heib <mheib@...hat.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>


> ---
...
> --
> 2.50.1