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: <20260122074602.3c41e8c1@kernel.org>
Date: Thu, 22 Jan 2026 07:46:02 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Dragos Tatulea <dtatulea@...dia.com>
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 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?

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ