netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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,



  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).