Re: [PATCH net-next 4/6] net: use netdev_queue_config() for mp restart

[Jakub Kicinski <kuba@kernel.org>]

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.