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: <20250905122530.GB553991@horms.kernel.org>
Date: Fri, 5 Sep 2025 13:25:30 +0100
From: Simon Horman <horms@...nel.org>
To: mheib@...hat.com
Cc: intel-wired-lan@...ts.osuosl.org, przemyslawx.patynowski@...el.com,
	jiri@...nulli.us, netdev@...r.kernel.org, jacob.e.keller@...el.com,
	aleksandr.loktionov@...el.com, anthony.l.nguyen@...el.com,
	przemyslaw.kitszel@...el.com
Subject: Re: [PATCH net-next,v3,2/2] i40e: support generic devlink param
 "max_mac_per_vf"

On Thu, Sep 04, 2025 at 12:43:05AM +0300, mheib@...hat.com wrote:
> 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@redhat.com
>   https://lore.kernel.org/netdev/20250823094952.182181-1-mheib@redhat.com
> 
> Signed-off-by: Mohammad Heib <mheib@...hat.com>
> ---
>  Documentation/networking/devlink/i40e.rst     | 32 +++++++++++++
>  drivers/net/ethernet/intel/i40e/i40e.h        |  4 ++
>  .../net/ethernet/intel/i40e/i40e_devlink.c    | 48 ++++++++++++++++++-
>  .../ethernet/intel/i40e/i40e_virtchnl_pf.c    | 31 ++++++++----
>  4 files changed, 105 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/networking/devlink/i40e.rst b/Documentation/networking/devlink/i40e.rst
> index d3cb5bb5197e..524524fdd3de 100644
> --- a/Documentation/networking/devlink/i40e.rst
> +++ b/Documentation/networking/devlink/i40e.rst
> @@ -7,6 +7,38 @@ i40e devlink support
>  This document describes the devlink features implemented by the ``i40e``
>  device driver.
>  
> +Parameters
> +==========
> +
> +.. list-table:: Generic parameters implemented
> +    :widths: 5 5 90
> +
> +    * - Name
> +      - Mode
> +      - Notes
> +    * - ``max_mac_per_vf``
> +      - runtime
> +      - Controls the maximum number of MAC addresses a VF can use
> +        on i40e devices.
> +
> +        By default (``0``), the driver enforces its internally calculated per-VF
> +        MAC filter limit, which is based on the number of allocated VFS.
> +
> +        If set to a non-zero value, this parameter acts as a strict cap:
> +        the driver will use the user-provided value instead of its internal
> +        calculation.
> +
> +        **Important notes:**
> +        - MAC filters are a **shared hardware resource** across all VFs.

Sorry for not noticing this before sending my previous response.

make htmldocs is unhappy about the line above. Could you look into it?

.../i40e.rst:33: ERROR: Unexpected indentation. [docutils]

> +          Setting a high value may cause other VFs to be starved of filters.
> +
> +        - This value is a **theoretical maximum**. The hardware may return
> +          errors when its absolute limit is reached, regardless of the value
> +          set here.
> +
> +        The default value is ``0`` (internal calculation is used).
> +
> +

...