netdev - Re: [iwl-next] ice, irdma: Add rdma_qp_limits

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: <4513322a-28a8-4990-a7c6-f2a0d5675720@intel.com>
Date: Thu, 11 Sep 2025 21:51:07 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Leon Romanovsky <leon@...nel.org>, Tatyana Nikolova
	<tatyana.e.nikolova@...el.com>
CC: <jiri@...nulli.us>, <intel-wired-lan@...ts.osuosl.org>,
	<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>,
	<anthony.l.nguyen@...el.com>, Jakub Kicinski <kuba@...nel.org>, Mohammad Heib
	<mheib@...hat.com>
Subject: Re: [iwl-next] ice, irdma: Add rdma_qp_limits_sel devlink parameter
 for irdma

On 9/10/25 14:13, Leon Romanovsky wrote:
> On Wed, Sep 10, 2025 at 09:41:14AM +0200, Przemek Kitszel wrote:
>> On 9/9/25 14:20, Leon Romanovsky wrote:
>>> On Thu, Sep 04, 2025 at 02:57:19PM -0500, Tatyana Nikolova wrote:
>>>> Add a devlink parameter to switch between different QP resource profiles
>>>> (max number of QPs) supported by irdma for Intel Ethernet 800 devices. The
>>>> rdma_qp_limits_sel is translated into an index in the rsrc_limits_table to
>>>> select a power of two number between 1 and 256 for max supported QPs (1K-256K).
>>>> To reduce the irdma memory footprint, set the rdma_qp_limits_sel default value
>>>> to 1 (max 1K QPs).
>>>>
>>>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
>>>> Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@...el.com>
>>>> ---
>>>> Since the changes to irdma are minor, this is targeted to iwl-next/net-next.
>>>
>>> <...>
>>>
>>>>    #define DEVLINK_LOCAL_FWD_DISABLED_STR "disabled"
>>>>    #define DEVLINK_LOCAL_FWD_ENABLED_STR "enabled"
>>>>    #define DEVLINK_LOCAL_FWD_PRIORITIZED_STR "prioritized"
>>>> @@ -1621,6 +1723,7 @@ enum ice_param_id {
>>>>    	ICE_DEVLINK_PARAM_ID_BASE = DEVLINK_PARAM_GENERIC_ID_MAX,
>>>>    	ICE_DEVLINK_PARAM_ID_TX_SCHED_LAYERS,
>>>>    	ICE_DEVLINK_PARAM_ID_LOCAL_FWD,
>>>> +	ICE_DEVLINK_PARAM_ID_RDMA_QP_LIMITS_SEL,
>>>>    };
>>>
>>> I was under impression that driver-specific devlink knobs are not
>>> allowed. Was this limitation changed for Intel?
>>
>> I'm not aware of such limitation.
> 
> It is possible that my impression was wrong.
> 
>> It's always better to have generic params, but some knobs are not likely
>> to be reused; anyway it would be easy to convert into generic.
> 
> Unlikely, you will need to keep old parameter and new at the same time
> for backward compatibility reasons.

you are right in numeric sense, but the command will be the same
(so we will end up with one wrapper func/redirection),

or perhaps we could go crazy and say that we have stable uAPI
(on "string name level") instead of stable uABI (given number mapped
into ice-set-rdma-qp-limits) :)

> 
>>
>> To have this particular param more generic-ready, we have converted from
>> our internal format (values were 0...7, mapped into some powers of two)
>> to what one could imagine other drivers would like to add at some point
>> (perhaps multiplying the user-provided value by 1K is unnecessarily
>> complicating adoption for small NICs, IDK?).
>>
>> Do you believe this should be switched to generic now (instead of when
>> there is a future user)?
>> What about a name (this should be kept forever)?
> 
> mlx5 has .log_max_qp in mlx5_profile which looks similar to what you are
> proposing here, so RDMA_QP_LIMITS sounds fine to me.

thanks!
"SEL" part in our current proposal somewhat implies that we have a whole
bunch of limits that this particular number imposes/causes
for just QP, I would even say "rdma_qp_limit"

> 
>>
>> side note:
>> We are also going to add yet another param, now used only by intel, but
>> we do so as a generic one: "max number of MAC addrs for VF in i40e", see
>> https://lore.kernel.org/intel-wired-lan/20250907100454.193420-1-mheib@redhat.com/T/#t
>>
>>
>>>
>>> Thanks
>>