From: Johannes Berg <johannes@sipsolutions.net>
To: Vasanthakumar Thiagarajan <quic_vthiagar@quicinc.com>
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: Tue, 09 Aug 2022 20:15:20 +0200 [thread overview]
Message-ID: <103f62efc89d86773fbd07729326f3ba08f4ea23.camel@sipsolutions.net> (raw)
In-Reply-To: <20220802065019.20791-3-quic_vthiagar@quicinc.com>
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?
>
> 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?
OTOH, could there be races, e.g. while disabling a link?
johannes
next prev parent reply other threads:[~2022-08-09 18:42 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 [this message]
2022-08-11 10:28 ` Vasanthakumar Thiagarajan
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=103f62efc89d86773fbd07729326f3ba08f4ea23.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_vthiagar@quicinc.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 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.