From: Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>
Subject: Re: [RFC 2/2] wifi: mac80211: use link_id from ieee80211_rx_status to retrieve rx link
Date: Thu, 11 Aug 2022 15:58:27 +0530 [thread overview]
Message-ID: <124e5f40-04b4-21be-9e37-bc01633e8e7a@quicinc.com> (raw)
In-Reply-To: <103f62efc89d86773fbd07729326f3ba08f4ea23.camel@sipsolutions.net>
On 8/9/2022 11:45 PM, Johannes Berg wrote:
> On Tue, 2022-08-02 at 12:20 +0530, Vasanthakumar Thiagarajan wrote:
>> Fill rx.link with respective data_link from the reported link_id
>> in rx_status. Any link_id > 15 is invalid. Non-MLO connections
>> can use either 0 or 15 as the link_id. Please note that link_id
>> 0 is used with non-MLO connections to avoid changes in the
>> drivers not supporting MLO. For a 802.11 MLD address translated
>> frame, driver must report the right link_id for the
>> frame to get processed. When processing 802.3 frame format,
>> link_id is not that critical, used only with stats update.
>> In such case, all the stats will be updated for the deflink.
>
> I think it might be worth splitting this patch a bit different - putting
> some parts into the first patch already (that fill rx.link_id), and
> keeping some others (statistics etc.) in this patch, which is then more
> related to statistics?
Sure.
>
>>
>> if (rx->link_id >= 0) {
>> - link = rcu_dereference(rx->sdata->link[rx->link_id]);
>> -
>> + link = rcu_dereference(sdata->link[rx->link_id]);
>
> that has some spurious whitespace changes
>
>> + /*
>> + * TODO: In MLO, should the frame be dropped if the right link_id is not
>> + * available? Or may be it is fine in the current form to proceed with
>> + * the frame processing because with frame being in 802.3 format,
>> + * link_id is used only for stats purpose and updating the stats on
>> + * the deflink is fine?
>> + */
>> + if (pubsta->mlo && status->link_id != IEEE80211_LINK_UNSPECIFIED)
>> + rx.link_id = status->link_id;
>
> If the driver *does* give a link ID, it better be valid?
Sure, we can remove IEEE80211_LINK_UNSPECIFIED. If now valid
link_id is set for an MLO link, we still try to retrieve it from
the addr2 in case the MLD address translation is not done in the
lower layers but when this happens with already translated packets
then we may need to drop the packet?
>
> OTOH, could there be races, e.g. while disabling a link?
I assume this is for the packets where the received on a
link which is disabled? May be driver sets that link but
that link will not be valid in mac80211 while processing
this packet and the packet will be dropped? Or may be
a different race you are mentioning?
Vasanth
next prev parent reply other threads:[~2022-08-11 10:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-02 6:50 [RFC 0/2] wifi: mac80211: extend rx API with link_id for MLO connection Vasanthakumar Thiagarajan
2022-08-02 6:50 ` [RFC 1/2] wifi: mac80211: add a new field in ieee80211_rx_status for link id Vasanthakumar Thiagarajan
2022-08-02 15:28 ` Jeff Johnson
2022-08-03 16:46 ` Vasanthakumar Thiagarajan
2022-08-09 18:12 ` Johannes Berg
2022-08-11 9:31 ` Vasanthakumar Thiagarajan
2022-08-02 6:50 ` [RFC 2/2] wifi: mac80211: use link_id from ieee80211_rx_status to retrieve rx link Vasanthakumar Thiagarajan
2022-08-09 18:15 ` Johannes Berg
2022-08-11 10:28 ` Vasanthakumar Thiagarajan [this message]
2023-01-19 20:57 ` Johannes Berg
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=124e5f40-04b4-21be-9e37-bc01633e8e7a@quicinc.com \
--to=quic_vthiagar@quicinc.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.