This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:

   commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
   commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.

Before that to happen, workqueue users must be converted to the better named
new workqueues with no intended behaviour changes:

   system_wq -> system_percpu_wq
   system_unbound_wq -> system_dfl_wq

This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.

Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
 drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index 252259993022..6b84e728d29d 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -2022,7 +2022,7 @@ static void idpf_tx_read_tstamp(struct idpf_tx_queue *txq, struct sk_buff *skb)
 		/* Fetch timestamp from completion descriptor through
 		 * virtchnl msg to report to stack.
 		 */
-		queue_work(system_unbound_wq, txq->tstamp_task);
+		queue_work(system_dfl_wq, txq->tstamp_task);
 		break;
 	}
 
-- 
2.53.0

On 3/13/26 16:09, Marco Crivellari wrote:
> This patch continues the effort to refactor workqueue APIs, which has begun
> with the changes introducing new workqueues and a new alloc_workqueue flag:
> 
>     commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
>     commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
> 
> The point of the refactoring is to eventually alter the default behavior of
> workqueues to become unbound by default so that their workload placement is
> optimized by the scheduler.

this wording kinda scared me, but after reading linked commits, there is
nothing to worry about, as there are no functional changes in this patch

Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

> 
> Before that to happen, workqueue users must be converted to the better named
> new workqueues with no intended behaviour changes:
> 
>     system_wq -> system_percpu_wq
>     system_unbound_wq -> system_dfl_wq
> 
> This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
> removed in the future.
> 
> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
>   drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 252259993022..6b84e728d29d 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -2022,7 +2022,7 @@ static void idpf_tx_read_tstamp(struct idpf_tx_queue *txq, struct sk_buff *skb)
>   		/* Fetch timestamp from completion descriptor through
>   		 * virtchnl msg to report to stack.
>   		 */
> -		queue_work(system_unbound_wq, txq->tstamp_task);
> +		queue_work(system_dfl_wq, txq->tstamp_task);
>   		break;
>   	}
>

On Fri, Mar 13, 2026 at 5:09 PM Przemek Kitszel
<przemyslaw.kitszel@intel.com> wrote:
> [...]
> this wording kinda scared me, but after reading linked commits, there is
> nothing to worry about, as there are no functional changes in this patch
>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

Hi,

Sorry for the late reply. Yes, correct: there are no functional changes.

Thanks!
-- 

Marco Crivellari

SUSE Labs

On Fri, 13 Mar 2026 17:08:57 +0100 Przemek Kitszel wrote:
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

Process question - even tho you are also a maintainer I only read
Tony's tags as "please apply directly". LMK if that's right, I'll
try to remember / make a note..

On 3/14/2026 9:10 AM, Jakub Kicinski wrote:
> On Fri, 13 Mar 2026 17:08:57 +0100 Przemek Kitszel wrote:
>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> 
> Process question - even tho you are also a maintainer I only read
> Tony's tags as "please apply directly". LMK if that's right, I'll
> try to remember / make a note..

I talked to Przemek about this a little this morning. Since the 
Reviewed-by tag is used more prevalently in our process, perhaps an 
Acked-by could mean take this directly and the Reviewed-by keeps the 
same process of going through IWL. Other thought would be to explicitly 
ask/state for it to get taken directly. Open to other ideas as well if 
there's something else you'd prefer.

Thanks,
Tony

On Mon, 16 Mar 2026 09:58:29 -0700 Tony Nguyen wrote:
> On 3/14/2026 9:10 AM, Jakub Kicinski wrote:
> > On Fri, 13 Mar 2026 17:08:57 +0100 Przemek Kitszel wrote:  
> >> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>  
> > 
> > Process question - even tho you are also a maintainer I only read
> > Tony's tags as "please apply directly". LMK if that's right, I'll
> > try to remember / make a note..  
> 
> I talked to Przemek about this a little this morning. Since the 
> Reviewed-by tag is used more prevalently in our process, perhaps an 
> Acked-by could mean take this directly and the Reviewed-by keeps the 
> same process of going through IWL. Other thought would be to explicitly 
> ask/state for it to get taken directly. Open to other ideas as well if 
> there's something else you'd prefer.

Sounds complicated :S Let me continue ignoring Przemek's tags for the
purpose of direct application. I guess it's more about who sends the
PRs than who is a maintainer. If you send PRs I naturally never see
your review tags, as the patches will eventually come out with your SoB.

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jakub Kicinski
> Sent: Monday, March 16, 2026 12:41 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; intel-wired-
> lan@lists.osuosl.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Paolo
> Abeni <pabeni@redhat.com>
> Subject: Re: [Intel-wired-lan] [PATCH] idpf: Replace use of
> system_unbound_wq with system_dfl_wq
> 
> On Mon, 16 Mar 2026 09:58:29 -0700 Tony Nguyen wrote:
> > On 3/14/2026 9:10 AM, Jakub Kicinski wrote:
> > > On Fri, 13 Mar 2026 17:08:57 +0100 Przemek Kitszel wrote:
> > >> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> > >
> > > Process question - even tho you are also a maintainer I only read
> > > Tony's tags as "please apply directly". LMK if that's right, I'll
> > > try to remember / make a note..
> >
> > I talked to Przemek about this a little this morning. Since the
> > Reviewed-by tag is used more prevalently in our process, perhaps an
> > Acked-by could mean take this directly and the Reviewed-by keeps the
> > same process of going through IWL. Other thought would be to
> > explicitly ask/state for it to get taken directly. Open to other ideas
> > as well if there's something else you'd prefer.
> 
> Sounds complicated :S Let me continue ignoring Przemek's tags for the
> purpose of direct application. I guess it's more about who sends the PRs than
> who is a maintainer. If you send PRs I naturally never see your review tags, as
> the patches will eventually come out with your SoB.

Tested-by: Samuel Salin <Samuel.salin@intel.com>