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).
>> +
>> +
>
> ...
>
next prev parent 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).