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

[Simon Horman <horms@kernel.org>]

On Thu, Aug 07, 2025 at 09:17:30AM -0700, Jacob Keller wrote:
> 
> 
> On 8/5/2025 12:52 PM, Simon Horman wrote:
> > On Tue, Aug 05, 2025 at 09:40:42AM -0400, David Hill wrote:
> >> 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 <dhill@redhat.com>
> > 
> > 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.