From: mohammad heib <mheib@redhat.com>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Jiri Pirko <jiri@resnulli.us>
Cc: anthony.l.nguyen@intel.com, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, Jacob Keller <jacob.e.keller@intel.com>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net] i40e: add devlink param to control VF MAC address limit
Date: Sat, 23 Aug 2025 12:55:26 +0300 [thread overview]
Message-ID: <f2a0eb8b-2238-4bd2-bc81-eb0284fea6c8@redhat.com> (raw)
In-Reply-To: <41eae08f-5f77-4099-bcd4-ccc7bbcf6426@intel.com>
Hi,
Thank you for the review. All comments have been addressed in v2.
On 8/22/25 12:09 PM, Przemek Kitszel wrote:
> On 8/22/25 01:39, mheib@redhat.com wrote:
>> From: Mohammad Heib <mheib@redhat.com>
>>
>> This patch introduces a new devlink runtime parameter
>> to control whether the VF MAC filter limit feature is
>> enabled or disabled.
>>
>> When the parameter is set to non-zero, the driver enforces the per-VF
>> MAC
>> filter limit calculated from the number of allocated VFs and ports.
>> When the parameter is unset (zero), no limit is applied and behavior
>> remains as before commit cfb1d572c986
>> ("i40e: Add ensurance of MacVlan resources for every trusted VF").
>>
>> This implementation allows us to toggle the feature through devlink
>> while preserving old behavior. In the future, the parameter can be
>> extended to represent a configurable "max MACs per VF" value, but for
>> now it acts as a simple on/off switch.
>>
>> Example command to enable per-vf mac limit:
>> - devlink dev param set pci/0000:3b:00.0 name max_mac_per_vf \
>> value 1 \
>> cmode runtime
>>
>> Fixes: cfb1d572c986 ("i40e: Add ensurance of MacVlan resources for
>> every trusted VF")
>> Signed-off-by: Mohammad Heib <mheib@redhat.com>
>
> thank you for the patch, I have a few questions/objections
>
> 1. it git-conflicts with [1], please post your next revision based on
> Tony's (fixes) tree dev-queue branch [2]
>
> 2a. it is good practice to link to the previous discussions, and CC
> individuals involved (Jake, Simon)
>
> 2b. for changes that utilize given subsystem (devlink), you need to CC
> respective maintainers (Jiri)
>
> 3. it would really be better to treat not-zero values as strict limit
>
> 4. this idea is not limited to i40e, the parameter should be global
> (for all drivers to implement), as it seems generic enough
>
> 5. when someone will make a per-given-VF param, this one will not be
> deprecated but will still work as a cap (max) value. (Leaving it at
> zero will be ofc perfectly fine).
Sure, I would be happy to add this to other drivers. Currently, I’m not
aware of any other driver that has a per-VF MAC limit implemented.
If you know of any, please point me to them.
Otherwise, I will go through the drivers I’m working with and check
whether they have such a limit or not.
>
> [1]
> https://lore.kernel.org/intel-wired-lan/20250813104552.61027-9-przemyslaw.kitszel@intel.com/T/#mac68de249365b8c4fa83054592dd98f0f789fab4
>
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git/log/?h=dev-queue
>
>> ---
>> Documentation/networking/devlink/i40e.rst | 19 +++++++
>> drivers/net/ethernet/intel/i40e/i40e.h | 4 ++
>> .../net/ethernet/intel/i40e/i40e_devlink.c | 56 ++++++++++++++++++-
>> .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 14 ++++-
>> 4 files changed, 89 insertions(+), 4 deletions(-)
>>
>
Thanks,
next prev parent reply other threads:[~2025-08-23 9:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 23:39 [PATCH net] i40e: add devlink param to control VF MAC address limit mheib
2025-08-22 9:09 ` Przemek Kitszel
2025-08-23 9:55 ` mohammad heib [this message]
2025-08-22 19:41 ` [Intel-wired-lan] " Loktionov, Aleksandr
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=f2a0eb8b-2238-4bd2-bc81-eb0284fea6c8@redhat.com \
--to=mheib@redhat.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 \
/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).