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] [day] [month] [year] [list]
Message-ID: <6d7fdf16-3ed8-47b2-a872-164f1b6d5937@intel.com>
Date: Wed, 20 Aug 2025 13:35:52 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: mohammad heib <mheib@...hat.com>, Simon Horman <horms@...nel.org>
CC: David Hill <dhill@...hat.com>, <netdev@...r.kernel.org>,
	<anthony.l.nguyen@...el.com>, <przemyslaw.kitszel@...el.com>,
	<andrew+netdev@...n.ch>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH 2/2] PATCH: i40e Add module option to disable max VF limit



On 8/20/2025 6:09 AM, mohammad heib wrote:
> Hi Simon, Jacob,
> 
> I’ve also been examining this issue, as it’s affecting us.
> I agree that handling the number of allowed filters per VF as a devlink 
> resource is the best long-term approach.
> However, currently in i40e, we only create a devlink port per PF and no 
> devlink ports per VF.

Cross-PF interaction of a global resource is also tricky. Hm.

> Implementing the resource-per-VF approach would therefore require some 
> extra work.
> For now, could we adopt Simon’s devlink parameter suggestion as a 
> temporary solution and consider adding the resource-based approach in 
> the future?

I do agree that its a much larger ask to implement ports and such in
addition.My only concern is we would then likely want to support the
parameter in perpetuity. It is generally preferred that we don't remove
things in the future since it is a pain for software compatibility.
Technically, I don't know if that truly falls under "user space API
changing" if a single driver changes behavior.. but its definitely
frowned on if done without a very good reason. Perhaps there is a way to
make sure parameter works ok even once resources get added in the
future, to mitigate this concern?


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ