Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Intel-wired-lan] [PATCH] ice: Unbind the workqueue
       [not found] <20240922222420.18009-1-frederic@kernel.org>
@ 2024-09-23  8:57 ` Przemek Kitszel
  2024-09-23 18:28   ` Tony Nguyen
  0 siblings, 1 reply; 4+ messages in thread
From: Przemek Kitszel @ 2024-09-23  8:57 UTC (permalink / raw)
  To: Frederic Weisbecker, Tony Nguyen
  Cc: intel-wired-lan@lists.osuosl.org, LKML, Larysa Zaremba

On 9/23/24 00:24, Frederic Weisbecker wrote:
> The ice workqueue doesn't seem to rely on any CPU locality and should
> therefore be able to run on any CPU. In practice this is already
> happening through the unbound ice_service_timer that may fire anywhere
> and queue the workqueue accordingly to any CPU.
> 
> Make this official so that the ice workqueue is only ever queued to
> housekeeping CPUs on nohz_full.
> 
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> ---
>   drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index ea780d468579..70990f42ac05 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5924,7 +5924,7 @@ static int __init ice_module_init(void)
>   
>   	ice_adv_lnk_speed_maps_init();
>   
> -	ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME);
> +	ice_wq = alloc_workqueue("%s", WQ_UNBOUND, 0, KBUILD_MODNAME);
>   	if (!ice_wq) {
>   		pr_err("Failed to create workqueue\n");
>   		return status;

Thank you for the patch, it would make sense for our iwl-next tree,
with such assumption:
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>

@Tony, do you want it resent with target tree in the subject?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Intel-wired-lan] [PATCH] ice: Unbind the workqueue
  2024-09-23  8:57 ` [Intel-wired-lan] [PATCH] ice: Unbind the workqueue Przemek Kitszel
@ 2024-09-23 18:28   ` Tony Nguyen
  2024-10-07 10:29     ` Frederic Weisbecker
  0 siblings, 1 reply; 4+ messages in thread
From: Tony Nguyen @ 2024-09-23 18:28 UTC (permalink / raw)
  To: Przemek Kitszel, Frederic Weisbecker
  Cc: intel-wired-lan@lists.osuosl.org, LKML, Larysa Zaremba



On 9/23/2024 1:57 AM, Przemek Kitszel wrote:
> On 9/23/24 00:24, Frederic Weisbecker wrote:
>> The ice workqueue doesn't seem to rely on any CPU locality and should
>> therefore be able to run on any CPU. In practice this is already
>> happening through the unbound ice_service_timer that may fire anywhere
>> and queue the workqueue accordingly to any CPU.
>>
>> Make this official so that the ice workqueue is only ever queued to
>> housekeeping CPUs on nohz_full.
>>
>> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
>> ---
>>   drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c 
>> b/drivers/net/ethernet/intel/ice/ice_main.c
>> index ea780d468579..70990f42ac05 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_main.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
>> @@ -5924,7 +5924,7 @@ static int __init ice_module_init(void)
>>       ice_adv_lnk_speed_maps_init();
>> -    ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME);
>> +    ice_wq = alloc_workqueue("%s", WQ_UNBOUND, 0, KBUILD_MODNAME);
>>       if (!ice_wq) {
>>           pr_err("Failed to create workqueue\n");
>>           return status;
> 
> Thank you for the patch, it would make sense for our iwl-next tree,
> with such assumption:
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> 
> @Tony, do you want it resent with target tree in the subject?

No, I can apply this as-is but please remember to designate a tree for 
future patches.

Thanks,
Tony

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Intel-wired-lan] [PATCH] ice: Unbind the workqueue
  2024-09-23 18:28   ` Tony Nguyen
@ 2024-10-07 10:29     ` Frederic Weisbecker
  2024-10-07 21:42       ` Tony Nguyen
  0 siblings, 1 reply; 4+ messages in thread
From: Frederic Weisbecker @ 2024-10-07 10:29 UTC (permalink / raw)
  To: Tony Nguyen
  Cc: Przemek Kitszel, intel-wired-lan@lists.osuosl.org, LKML,
	Larysa Zaremba

Le Mon, Sep 23, 2024 at 11:28:20AM -0700, Tony Nguyen a écrit :
> 
> 
> On 9/23/2024 1:57 AM, Przemek Kitszel wrote:
> > On 9/23/24 00:24, Frederic Weisbecker wrote:
> > > The ice workqueue doesn't seem to rely on any CPU locality and should
> > > therefore be able to run on any CPU. In practice this is already
> > > happening through the unbound ice_service_timer that may fire anywhere
> > > and queue the workqueue accordingly to any CPU.
> > > 
> > > Make this official so that the ice workqueue is only ever queued to
> > > housekeeping CPUs on nohz_full.
> > > 
> > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> > > ---
> > >   drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> > > b/drivers/net/ethernet/intel/ice/ice_main.c
> > > index ea780d468579..70990f42ac05 100644
> > > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > > @@ -5924,7 +5924,7 @@ static int __init ice_module_init(void)
> > >       ice_adv_lnk_speed_maps_init();
> > > -    ice_wq = alloc_workqueue("%s", 0, 0, KBUILD_MODNAME);
> > > +    ice_wq = alloc_workqueue("%s", WQ_UNBOUND, 0, KBUILD_MODNAME);
> > >       if (!ice_wq) {
> > >           pr_err("Failed to create workqueue\n");
> > >           return status;
> > 
> > Thank you for the patch, it would make sense for our iwl-next tree,
> > with such assumption:
> > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> > 
> > @Tony, do you want it resent with target tree in the subject?
> 
> No, I can apply this as-is but please remember to designate a tree for
> future patches.

Sorry I didn't know about any tree. I can't even find where iwl-next is
hosted.

Thanks.

> Thanks,
> Tony

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Intel-wired-lan] [PATCH] ice: Unbind the workqueue
  2024-10-07 10:29     ` Frederic Weisbecker
@ 2024-10-07 21:42       ` Tony Nguyen
  0 siblings, 0 replies; 4+ messages in thread
From: Tony Nguyen @ 2024-10-07 21:42 UTC (permalink / raw)
  To: Frederic Weisbecker
  Cc: Przemek Kitszel, intel-wired-lan@lists.osuosl.org, LKML,
	Larysa Zaremba



On 10/7/2024 3:29 AM, Frederic Weisbecker wrote:
> Le Mon, Sep 23, 2024 at 11:28:20AM -0700, Tony Nguyen a écrit :

...
>>> Thank you for the patch, it would make sense for our iwl-next tree,
>>> with such assumption:
>>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>>>
>>> @Tony, do you want it resent with target tree in the subject?
>>
>> No, I can apply this as-is but please remember to designate a tree for
>> future patches.
> 
> Sorry I didn't know about any tree. I can't even find where iwl-next is
> hosted.

The information is here: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n11413

For bug fixes, net-queue tree is used and next-queue for other content 
(dev-queue branch for both).

I did find that I crossed this patch with another and found that the 
initial send of this did not include the Intel Wired LAN list. I'll 
resend the patch to include the proper list so that patchworks can pick 
this up.

Thanks,
Tony


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-10-07 21:42 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20240922222420.18009-1-frederic@kernel.org>
2024-09-23  8:57 ` [Intel-wired-lan] [PATCH] ice: Unbind the workqueue Przemek Kitszel
2024-09-23 18:28   ` Tony Nguyen
2024-10-07 10:29     ` Frederic Weisbecker
2024-10-07 21:42       ` Tony Nguyen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox