[<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