netdev - Re: [PATCH net-next,v2,1/2] devlink: Add new "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: <7a6d4052-537d-4de6-b1af-a26e362704ab@redhat.com>
Date: Thu, 4 Sep 2025 00:44:12 +0300
From: mohammad heib <mheib@...hat.com>
To: Jacob Keller <jacob.e.keller@...el.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

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.

On 9/3/25 11:11 PM, Jacob Keller wrote:
> 
> 
> On 9/3/2025 12:02 PM, mheib@...hat.com wrote:
>> From: Mohammad Heib <mheib@...hat.com>
>>
>> Add a new device generic parameter to controls the maximum
>> number of MAC filters allowed per VF.
>>
>> While this parameter is named `max_mac_per_vf`, the exact enforcement
>> policy may vary between drivers. For example, i40e applies this limit
>> only to trusted VFs, whereas other drivers may choose to apply it
>> uniformly across all VFs. The goal is to provide a consistent devlink
>> interface, while allowing flexibility for driver-specific behavior.
>>
> 
> Would it make more sense to apply the limit to all VFs if set, and apply
> the default variable behavior for when its unset? This would avoid the
> need to have this much flexibility and latitude for each driver.
> 
> It seems like that wouldn't be too difficult.