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
next prev parent 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).