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: <IA3PR11MB8986F453579349C3518B312CE501A@IA3PR11MB8986.namprd11.prod.outlook.com>
Date: Wed, 3 Sep 2025 09:07:37 +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,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 9:58 AM
> 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,2/2] i40e: support generic devlink param
> "max_mac_per_vf"
> 
> From: Mohammad Heib <mheib@...hat.com>
> 
> Add support for the new generic devlink runtime parameter
> "max_mac_per_vf", which controls the maximum number of MAC addresses a
> trusted VF can use.


Good day Mohammad,

Thanks for working on this and for the clear explanation in the commit message.

I have a couple of questions and thoughts:

1) Scope of the parameter
    The name max_mac_per_vf is a bit ambiguous. From the description,
    it seems to apply only to trusted VFs, but the name does not make that obvious.
    Would it make sense to either:
	- Make the name reflect that (e.g., max_mac_per_trusted_vf), or
	- Introduce two separate parameters for trusted and untrusted VFs if both cases need to be handled differently?

2)Problem statement
    It would help to better understand the underlying problem this parameter is solving.
    Is the goal to enforce a global cap for all VFs, or to provide operators with a way
    to fine-tune per-VF limits? From my perspective, the most important part is
    clearly stating the problem and the use case.

3)Granularity
    If the intent is to give operators flexibility, a single global parameter might not be enough.
    For example, limiting the number of MAC filters per specific VF (or having different limits for trusted vs. untrusted)
    could be a real-world requirement. This patch doesn't seem to address that scenario.

Could you share more details about the use case and whether per-VF granularity was considered?

Thanks again for the work on this. Looking forward to your thoughts.

Best regards,
Aleksandr

> 
> By default (value 0), the driver enforces its internally calculated
> per-VF MAC filter limit. A non-zero value acts as a strict cap,
> overriding the internal calculation.
> 
> Please note that the configured value is only a theoretical maximum
> and a hardware limits may still apply.
> 
> - Previous discussion about this change:
>   https://lore.kernel.org/netdev/20250805134042.2604897-1-
> dhill@...hat.com
>   https://lore.kernel.org/netdev/20250823094952.182181-1-
> mheib@...hat.com
> 
> Signed-off-by: Mohammad Heib <mheib@...hat.com>
> ---

...

> --
> 2.50.1


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ