Message-ID: <c8e9a2c0-343c-4732-b2d1-1edf8a708765@intel.com>
Date: Wed, 3 Sep 2025 17:01:40 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: mohammad heib <mheib@...hat.com>, <intel-wired-lan@...ts.osuosl.org>
CC: <przemyslawx.patynowski@...el.com>, <jiri@...nulli.us>,
	<netdev@...r.kernel.org>, <horms@...nel.org>,
	<aleksandr.loktionov@...el.com>, <anthony.l.nguyen@...el.com>,
	<przemyslaw.kitszel@...el.com>
Subject: Re: [PATCH net-next,v2,1/2] devlink: Add new "max_mac_per_vf" generic
 device param



On 9/3/2025 2:44 PM, mohammad heib wrote:
> Hi Jacob,
> 
> Thanks for the review.
> 
> It’s indeed an easy change. I’m wondering why untrusted VFs were 
> originally limited to 16+2 MACs, and if changing this (overwriting that 
> behavior) could be risky.
> 
> Anyway, I applied your suggestions in v3.
> 

The limit appears to come from 5f527ba962e2 ("i40e: Limit the number of
MAC and VLAN addresses that can be added for VFs") which is from 2016.
The commit message unfortunately does not describe a reason for the
specific limit. Prior to this change, any VF could use any number of
MACs, and thus could cause resource starvation for all VFs. Curiously
this limit was set to 8 originally.

In 2017, this limit was increased by commit 4dbc56613962 ("i40e: Allow
untrusted VFs to have more filters") to 12 filters. It has some
justification:

> Our original filter limit of 8 was based on behavior that we saw from
> Linux VMs. Now we're running Other Operating Systems under KVM and we
> see that they commonly use more MAC filters. Since it seems weird to
> require people to enable trusted VFs just to boot their OS, bump the
> number of filters allowed by default.


In 2019 the limit was further increased to 18 via commit 06b6e2a2333e
("i40e: Able to add up to 16 MAC filters on an untrusted VF") which
increased the limit to up to 16 MAC filters (16 + 1 for broadcast and 1
for the default unicast address). Little to no justification is provided
as to why 16 was chosen.

I tried looking through internal change logs on the out-of-tree releases
we have for i40e, and it also has a limit of 18 (16 + 2). It looks this
change possibly came as part of a request from customers, which I cannot
find any publicly sharable information on.

Given all this, as far as I can tell the only thing that an untrusted VF
could do is consume more MAC filter resources that otherwise would go to
the PF or another VF. By allowing the system administrator to tune this
to any value, I think it gives more flexibility to all customers, and
will prevent us from needing to further continue to raise this limit to
one that matches their environment. There is an absolute upper bound of
MAC filters available in hardware, but each system may have many or few
VFs and can better use that limit with a control knob to limit untrusted
VFs to the appropriate maximum that is suitable within their constraints.

Going with resources (eventually) would allow even more flexibility by
not requiring the same limit on all VFs, and by providing clear limits
on the hardware upper bound to the userspace. However, I think that can
be handled separately, and this simple knob is a much needed step in the
right direction. Its clear we (Intel) have had to change this value *3*
times already just for i40e. (from 0 to 8, to 12, to 18).

I suspect ice also has the exact same limitation, and we can and should
generate a patch to enable the same behavior in ice. I have no problem
with doing that as a follow-up after this merges. No need to add more
work to your plate here.

Thanks,
Jake


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

Powered by blists - more mailing lists