linux-kernel - Re: [PATCH net-next v2 02/14] i40e: support generic devlink param "max_mac_per

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d39fc2bd-56bf-4c5b-99a2-398433238220@intel.com>
Date: Tue, 21 Oct 2025 13:39:27 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Jiri Pirko <jiri@...nulli.us>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "Simon
 Horman" <horms@...nel.org>, Jonathan Corbet <corbet@....net>, Tony Nguyen
	<anthony.l.nguyen@...el.com>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, Alexander Lobakin
	<aleksander.lobakin@...el.com>, <netdev@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Mohammad Heib
	<mheib@...hat.com>, Aleksandr Loktionov <aleksandr.loktionov@...el.com>,
	Rafal Romanowski <rafal.romanowski@...el.com>
Subject: Re: [PATCH net-next v2 02/14] i40e: support generic devlink param
 "max_mac_per_vf"

On 10/20/2025 6:25 PM, Jakub Kicinski wrote:
> On Thu, 16 Oct 2025 23:08:31 -0700 Jacob Keller wrote:
>> - The configured value is a theoretical maximum. Hardware limits may
>>   still prevent additional MAC addresses from being added, even if the
>>   parameter allows it.
> 
> Is "administrative policy" better than "theoretical max" ?
> 

That could be a bit more accurate.

> Also -- should we be scanning the existing state to check if some VM
> hasn't violated the new setting and error or at least return a extack
> to the user to warn that the policy is not currently adhered to?

My understanding here is that this enforces the VF to never go *above*
this value, but its possible some other hardware restriction (i.e. out
of filters) could prevent a VF from adding more filters even if the
value is set higher.

Basically, this sets the maximum allowed number of filters, but doesn't
guarantee that many filters are actually available, at least on X710
where filters are a shared resource and we do not have a good mechanism
to coordinate across PFs to confirm how many have been made available or
reserved already. (Until firmware rejects adding a filter because
resources are capped)

Thus, I don't think we need to scan to check anything here. VFs should
be unable to exceed this limit, and thats checked on filter add.

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