linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@kernel.org>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless\@vger.kernel.org"
	<linux-wireless@vger.kernel.org>,
	"Bernie Huang" <phhuang@realtek.com>
Subject: Re: [PATCH 2/5] wifi: rtw89: add function to wait for completion of TX skbs
Date: Wed, 12 Apr 2023 16:00:27 +0300	[thread overview]
Message-ID: <8735558dck.fsf@kernel.org> (raw)
In-Reply-To: <56831ba4f216daee09b3d9c9a7deaf5810cade34.camel@realtek.com> (Ping-Ke Shih's message of "Tue, 11 Apr 2023 13:01:36 +0000")

Ping-Ke Shih <pkshih@realtek.com> writes:

> On Tue, 2023-04-04 at 10:37 +0800, Ping-Ke Shih wrote:
>
>> On Mon, 2023-04-03 at 13:32 +0300, Kalle Valo wrote:
>> > I would expect that there's polling if you are waiting something from
>> > hardware, or maybe when implementing a spin lock, but not when waiting
>> > for another kernel thread. This just doesn't feel right but I don't have
>> > time to propose a good alternative either, sorry.
>> > 
>> 
>> I have found a solution that uses an owner variable with a spin lock
>> to determine which side to free completion object. Simply show two use
>> cases below:
>> 
>> Use case 1: (normal case; free completion object by work 1)
>>     work 1                                work 2
>>     wait
>>                                           (spin_lock)
>>                                           complete
>>                                           check & set owner --> owner = work1
>> 		                          (spin_unlock)
>>     wait ok
>>     (spin_lock)
>>     check & check owner --> free by work 1
>>     (spin_unlock)
>>     free completion
>> 
>> 
>> Use case 2: (timeout case; free completion object by work 2)
>>     work 1                                work 2
>>     wait
>>     wait timeout
>>     (spin_lock)
>>     check & set owner --> owner = work 2
>>     (spin_unlock)
>>                                          (spin_lock)
>>                                          completion
>>                                          check & set owner --> free by work 2
>>                                          (spin_unlock)
>>                                          free completion
>> 
>> I will apply this by v5.
>> 
>
> We have a better idea that use kfree_rcu() to free completion, so no
> need spin_lock(). Then, the use cases become below, and I have sent
> this change by v6.
>
> Use case 1: (normal case)
>     work 1                                work 2
>     (rcu_assign_pointer(wait))
>     wait
>                                           (rcu_read_lock)
>                                           wait = rcu_dereference();
>                                           if (wait)    --> wait != NULL
>                                               complete
>                                           (rcu_read_unlock)
>     wait ok
>     (rcu_assign_pointer(NULL))
>     kfree_rcu(completion)
>
>
> Use case 2: (timeout case)
>     work 1                                work 2
>     (rcu_assign_pointer(wait))
>     wait
>     wait timeout
>     (rcu_assign_pointer(NULL))
>     kfree_rcu(completion)
>                                           (rcu_read_lock)
>                                           wait = rcu_dereference();
>                                           if (wait)    --> wait == NULL
>                                               complete
>                                           (rcu_read_unlock)

Thanks, I haven't had a chance to look at v6 yet (nor v5 for that
matter) but at least based on this mail your idea looks much better than
polling.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2023-04-12 13:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10  3:46 [PATCH 0/5] wifi: rtw89: preparation of multiple interface concurrency support Ping-Ke Shih
2023-03-10  3:46 ` [PATCH 1/5] wifi: rtw89: 8852c: add beacon filter and CQM support Ping-Ke Shih
2023-03-15  8:31   ` Kalle Valo
2023-03-15  8:57     ` Ping-Ke Shih
2023-03-15 11:45       ` Ping-Ke Shih
2023-03-16 12:24         ` Ping-Ke Shih
2023-04-03 10:21       ` rtw88/rtw89: command/event structure handling Kalle Valo
2023-04-03 13:23         ` Kalle Valo
2023-04-03 14:09           ` Ping-Ke Shih
2023-04-03 18:06             ` Kalle Valo
2023-03-10  3:46 ` [PATCH 2/5] wifi: rtw89: add function to wait for completion of TX skbs Ping-Ke Shih
2023-03-15  8:39   ` Kalle Valo
2023-03-15 12:09     ` Ping-Ke Shih
2023-04-03 10:32       ` Kalle Valo
2023-04-04  2:38         ` Ping-Ke Shih
2023-04-11 13:01           ` Ping-Ke Shih
2023-04-12 13:00             ` Kalle Valo [this message]
2023-03-10  3:46 ` [PATCH 3/5] wifi: rtw89: add ieee80211::remain_on_channel ops Ping-Ke Shih
2023-03-10  3:46 ` [PATCH 4/5] wifi: rtw89: add flag check for power state Ping-Ke Shih
2023-03-10  3:46 ` [PATCH 5/5] wifi: rtw89: fix authentication fail during scan Ping-Ke Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735558dck.fsf@kernel.org \
    --to=kvalo@kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=phhuang@realtek.com \
    --cc=pkshih@realtek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).