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
