Thread (6 messages) flat view 6 messages, 3 authors, 2025-08-08

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

From: Simon Horman <horms@kernel.org>
Date: 2025-08-08 13:01:19

On Thu, Aug 07, 2025 at 09:17:30AM -0700, Jacob Keller wrote:

On 8/5/2025 12:52 PM, Simon Horman wrote:
quoted
On Tue, Aug 05, 2025 at 09:40:42AM -0400, David Hill wrote:
quoted
When a VF reaches the limit introduced in this commit [1], the driver
refuses to add any more MACs to the filter which changes the behavior
from previous releases and might break some NFVs which sometimes add
more VFs than the hardcoded limit of 18 and variable limit depending
on the number of VFs created on a given PF.   Disabling limit_mac_per_vf
would revert to previous behavior.

[1] commit cfb1d572c986 ("i40e: Add ensurance of MacVlan resources for every
trusted VF")

Signed-off-by: David Hill <redacted>
Hi David,

Unfortunately adding new module parameters to Ethernet drivers is discouraged.
I would suggest that devlink is an appropriate mechanism.
At a glance, my initial suggestion would be modeling this with devlink
resources?

If each VF has a devlink port in the host, we could create a resource
that is the number of allowed filters for each VF, and the host could
control this through the resource...

I think this might even let us nest a resource so we have one for the
parent which is the total amount available and each VF port could have
its amount available.

A devlink parameter could work but is a bit less flexible and doesn't
show you the hierarchy with the total available filters within the PF vs
what each VF is consuming.
Thanks Jacob,

For some reason I had not thought of modelling filters as a resource.
But I do agree that is is a promising approach.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help