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: <5ad712d1-47ce-446e-bc96-e03b72459eee@redhat.com>
Date: Sun, 7 Sep 2025 13:07:29 +0300
From: mohammad heib <mheib@...hat.com>
To: Simon Horman <horms@...nel.org>
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"

Hi Simon,

Thanks for the review i fixed it in v4.


On 9/5/25 3:25 PM, Simon Horman wrote:
> 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).
>> +
>> +
> 
> ...
>