[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <22e2c955-61b7-4a1e-ab91-21cd1906a604@redhat.com>
Date: Wed, 3 Sep 2025 13:05:48 +0300
From: mohammad heib <mheib@...hat.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
Cc: "przemyslawx.patynowski@...el.com" <przemyslawx.patynowski@...el.com>,
"jiri@...nulli.us" <jiri@...nulli.us>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"horms@...nel.org" <horms@...nel.org>,
"Keller, Jacob E" <jacob.e.keller@...el.com>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH net-next,2/2] i40e: support generic devlink param
"max_mac_per_vf"
Hello Aleksandr,
Thank you for your review.
On 9/3/25 12:07 PM, Loktionov, Aleksandr wrote:
>
>
>> -----Original Message-----
>> From: mheib@...hat.com <mheib@...hat.com>
>> Sent: Wednesday, September 3, 2025 9:58 AM
>> To: intel-wired-lan@...ts.osuosl.org
>> Cc: przemyslawx.patynowski@...el.com; jiri@...nulli.us;
>> netdev@...r.kernel.org; horms@...nel.org; Keller, Jacob E
>> <jacob.e.keller@...el.com>; Loktionov, Aleksandr
>> <aleksandr.loktionov@...el.com>; Nguyen, Anthony L
>> <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@...el.com>; Mohammad Heib <mheib@...hat.com>
>> Subject: [PATCH net-next,2/2] i40e: support generic devlink param
>> "max_mac_per_vf"
>>
>> From: Mohammad Heib <mheib@...hat.com>
>>
>> Add support for the new generic devlink runtime parameter
>> "max_mac_per_vf", which controls the maximum number of MAC addresses a
>> trusted VF can use.
>
>
> Good day Mohammad,
>
> Thanks for working on this and for the clear explanation in the commit message.
>
> I have a couple of questions and thoughts:
>
> 1) Scope of the parameter
> The name max_mac_per_vf is a bit ambiguous. From the description,
> it seems to apply only to trusted VFs, but the name does not make that obvious.
> Would it make sense to either:
> - Make the name reflect that (e.g., max_mac_per_trusted_vf), or
> - Introduce two separate parameters for trusted and untrusted VFs if both cases need to be handled differently?
I agree that the name could be a bit confusing. Since this is a generic
devlink parameter, different devices may handle trusted and untrusted
VFs differently.
For i40e specifically, the device does treat trusted VFs differently
from untrusted ones, and this is documented in devlink/i40e.rst.
However, I chose a more general name to avoid creating a separate
devlink parameter for untrusted VFs, which likely wouldn’t be used.
On reflection, I should update the patch number 1 to remove the
**trusted VF** wording from the description to avoid implying that the
parameter only applies to trusted VFs.
>
> 2)Problem statement
> It would help to better understand the underlying problem this parameter is solving.
> Is the goal to enforce a global cap for all VFs, or to provide operators with a way
> to fine-tune per-VF limits? From my perspective, the most important part is
> clearly stating the problem and the use case.
>
My main goal here is to enforce a global cap for all VFs.
There was a long discussion [1] about this, and one of the ideas raised
was to create fine-tuned per-VF limits using devlink resources instead
of a parameter
However, currently in i40e, we only create a devlink port per PF and no
devlink ports per VF.
Implementing the resource-per-VF approach would therefore require some
extra work.
so i decided to go with this global cap for now.
[1] -
https://patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2-dhill@redhat.com/
> 3)Granularity
> If the intent is to give operators flexibility, a single global parameter might not be enough.
> For example, limiting the number of MAC filters per specific VF (or having different limits for trusted vs. untrusted)
> could be a real-world requirement. This patch doesn't seem to address that scenario.
>
> Could you share more details about the use case and whether per-VF granularity was considered?
>
> Thanks again for the work on this. Looking forward to your thoughts.
>
> Best regards,
> Aleksandr
>
please see -
https://patchwork.kernel.org/project/netdevbpf/patch/20250805134042.2604897-2-dhill@redhat.com/
>>
>> By default (value 0), the driver enforces its internally calculated
>> per-VF MAC filter limit. A non-zero value acts as a strict cap,
>> overriding the internal calculation.
>>
>> Please note that the configured value is only a theoretical maximum
>> and a hardware limits may still apply.
>>
>> - Previous discussion about this change:
>> https://lore.kernel.org/netdev/20250805134042.2604897-1-
>> dhill@...hat.com
>> https://lore.kernel.org/netdev/20250823094952.182181-1-
>> mheib@...hat.com
>>
>> Signed-off-by: Mohammad Heib <mheib@...hat.com>
>> ---
>
> ...
>
>> --
>> 2.50.1
>
Thank you,
Powered by blists - more mailing lists