netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mohammad heib <mheib@redhat.com>
To: Simon Horman <horms@kernel.org>
Cc: intel-wired-lan@lists.osuosl.org,
	przemyslawx.patynowski@intel.com, jiri@resnulli.us,
	netdev@vger.kernel.org, jacob.e.keller@intel.com,
	aleksandr.loktionov@intel.com, anthony.l.nguyen@intel.com,
	przemyslaw.kitszel@intel.com
Subject: Re: [PATCH net-next,v3,2/2] i40e: support generic devlink param "max_mac_per_vf"
Date: Sun, 7 Sep 2025 13:07:29 +0300	[thread overview]
Message-ID: <5ad712d1-47ce-446e-bc96-e03b72459eee@redhat.com> (raw)
In-Reply-To: <20250905122530.GB553991@horms.kernel.org>

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@redhat.com wrote:
>> From: Mohammad Heib <mheib@redhat.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@redhat.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).
>> +
>> +
> 
> ...
> 


  reply	other threads:[~2025-09-07 10:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 21:43 [PATCH net-next,v3,1/2] devlink: Add new "max_mac_per_vf" generic device param mheib
2025-09-03 21:43 ` [PATCH net-next,v3,2/2] i40e: support generic devlink param "max_mac_per_vf" mheib
2025-09-03 22:25   ` Jacob Keller
2025-09-05 11:46     ` Simon Horman
2025-09-05 23:29       ` Jacob Keller
2025-09-07 10:10       ` mohammad heib
2025-09-04  6:04   ` Loktionov, Aleksandr
2025-09-05 12:25   ` Simon Horman
2025-09-07 10:07     ` mohammad heib [this message]
2025-09-05 12:22 ` [PATCH net-next,v3,1/2] devlink: Add new "max_mac_per_vf" generic device param Simon Horman
2025-09-07  9:07   ` mohammad heib

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ad712d1-47ce-446e-bc96-e03b72459eee@redhat.com \
    --to=mheib@redhat.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=horms@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=netdev@vger.kernel.org \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=przemyslawx.patynowski@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).