netdev - Re: [PATCH net-next 4/6] net: use netdev_queue

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: <42c80a14-3d58-4e5b-b776-ffc31d70082d@nvidia.com>
Date: Thu, 22 Jan 2026 17:28:02 +0100
From: Dragos Tatulea <dtatulea@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org,
 michael.chan@...adcom.com, sdf@...ichev.me, almasrymina@...gle.com,
 asml.silence@...il.com, dw@...idwei.uk, daniel@...earbox.net
Subject: Re: [PATCH net-next 4/6] net: use netdev_queue_config() for mp
 restart



On 22.01.26 16:46, Jakub Kicinski wrote:
> On Thu, 22 Jan 2026 16:06:40 +0100 Dragos Tatulea wrote:
>>> @@ -195,8 +199,11 @@ void __net_mp_close_rxq(struct net_device *dev, unsigned int ifq_idx,
>>>  			 rxq->mp_params.mp_priv != old_p->mp_priv))
>>>  		return;
>>>  
>>> +	netdev_queue_config(dev, ifq_idx, &qcfg[0]);
>>>  	memset(&rxq->mp_params, 0, sizeof(rxq->mp_params));
>>> -	err = netdev_rx_queue_restart(dev, ifq_idx);
>>> +	netdev_queue_config(dev, ifq_idx, &qcfg[1]);
>>> +  
>> Is it ok to assume that on close we always resume to the default?
>> For now yes but maybe in the future we might want to save qcfg to the
>> state before mp_open.
> 
> When we add the ability to configure the params via Netlink we should
> insert another chunk into [__]netdev_queue_config().
> netdev_queue_config() should evaluate the config in reverse order of
> priority, so:
>  - get defaults
>  - get device-level config
>  - get per-queue config
>  - get MP overrides
> 
> On close we are clearing the MP overrides, since we don't have
> per-queue config we revert to defaults (as you say). But once there's
> some overlap with device or per-queue configs we'll go back to the next
> level of config in order of priority.
> 
> Did I understand the question right?
>
Yes, that was my point. The order that you mentioned was my concern as
well.

> FWIW I think something that'd be a major usability win would be to make
> MP presence imply per-queue HDS threshold of 0 automatically. So that'd
> probably be first on my list of knobs to extend the "priority" model to.
> 
You mean to set it to 0 during MP queue lifetime and then revert to
previous value according to the above priority list. Right?

>> With the very first rx-buf-len series it was possible to set a
>> rx-buf-len via YNL for a normal queue, switch to a MP queue and then
>> on MP queue close the configuration got switched to the default value
>> of rx-buf-len instead of what the user had configured. This was
>> not convenient.
> 
> Yes, not sure IIUC, but the fact that clearing the MP didn't
> automatically delete the MP-related setting was the main reason
> we ditched the full qcfg for this use case.
Ack.

Other than that, I reviewed the series and don't have any other
comment. So FWIW:

Reviewed-by: Dragos Tatulea <dtatulea@...dia.com>

Thanks,
Dragos