netdev - Re: [PATCH 2/2] PATCH: i40e Add module option to disable max VF limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <f5c3b451-0a8d-4146-8e47-be2c7e2d6284@redhat.com>
Date: Wed, 20 Aug 2025 16:09:20 +0300
From: mohammad heib <mheib@...hat.com>
To: Simon Horman <horms@...nel.org>
Cc: Jacob Keller <jacob.e.keller@...el.com>, David Hill <dhill@...hat.com>,
 netdev@...r.kernel.org, anthony.l.nguyen@...el.com,
 przemyslaw.kitszel@...el.com, andrew+netdev@...n.ch, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Subject: Re: [PATCH 2/2] PATCH: i40e Add module option to disable max VF limit

Hi Simon, Jacob,

I’ve also been examining this issue, as it’s affecting us.
I agree that handling the number of allowed filters per VF as a devlink 
resource is the best long-term approach.
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.
For now, could we adopt Simon’s devlink parameter suggestion as a 
temporary solution and consider adding the resource-based approach in 
the future?

On 8/20/25 2:33 PM, Mohammad Heib wrote:
> Hi Simon, Jacob,
>
> I’ve also been examining this issue, as it’s affecting us.
> I agree that handling the number of allowed filters per VF as a 
> devlink resource is the best long-term approach.
> 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.
> For now, could we adopt Simon’s devlink parameter suggestion as a 
> temporary solution and consider adding the resource-based approach in 
> the future?