From: David Lin <yu-hao.lin@nxp.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Brian Norris <briannorris@chromium.org>
Cc: Francesco Dolcini <francesco@dolcini.it>,
"kvalo@kernel.org" <kvalo@kernel.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pete Hsieh <tsung-hsien.hsieh@nxp.com>,
rafael.beims <rafael.beims@toradex.com>,
Francesco Dolcini <francesco.dolcini@toradex.com>
Subject: RE: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme
Date: Thu, 11 Apr 2024 07:57:34 +0000 [thread overview]
Message-ID: <DU0PR04MB9636AF728C818073435A0E90D1052@DU0PR04MB9636.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <7af985e13d3254de73f9d68e1ad4ad1f81b5fd59.camel@sipsolutions.net>
> From: Johannes Berg <johannes@sipsolutions.net>
> Sent: Thursday, April 11, 2024 1:57 AM
> To: David Lin <yu-hao.lin@nxp.com>; Brian Norris
> <briannorris@chromium.org>
> Cc: Francesco Dolcini <francesco@dolcini.it>; kvalo@kernel.org;
> linux-wireless@vger.kernel.org; linux-kernel@vger.kernel.org; Pete Hsieh
> <tsung-hsien.hsieh@nxp.com>; rafael.beims <rafael.beims@toradex.com>;
> Francesco Dolcini <francesco.dolcini@toradex.com>
> Subject: Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host
> mlme
>
> On Wed, 2024-04-10 at 10:33 +0000, David Lin wrote:
> >
> >
> > Take Rx data path as an example,
> > In current FW, BA stream setup and de-ampdu are handled in FW. Packet is
> converted to 802.3 before passing to host. Ampdu reordering is handled in host
> driver (Mwifiex) due to memory consideration. We used to work on a driver
> that uses RX_FLAG_8023. It was on an older Wi-Fi part which has more
> memory and powerful processor. But with this chip buffer required for
> reordering doesn’t fit FW memory.
> >
> > Ampdu reordering needs MAC 802.11 header, FW keeps the MAC header in
> packet descriptor since packet already 802.3 when arrive at driver. As packet
> descriptor only accessible in the driver, Mwifiex handles the reordering instead
> of using mac80211 reordering.
> >
> > With current FW design, to apply mac802.11 we either change FW to pass
> > packet in 802.11 format or driver needs to do the conversion back to
> > 802.11 (which I think doesn’t make sense)
> >
> > Given existing FW design, we think it’s difficult to apply mac80211.
>
> Hmm, I don't think so? If you have a mac80211 driver with RX_FLAG_8023,
> then of course mac80211 cannot do reordering, and you have to do it
> somewhere below. But that doesn't mean you necessarily _have_ to do it in
> hardware/firmware? You could do it in the driver, which you also have to do in
> a cfg80211 driver anyway, and that's OK. Due to usage of RSS, iwlwifi/mvm
> even does it internally, although it doesn't even have RX_FLAG_8023.
>
> But that goes into the direction I was talking about: the boundaries are getting
> fuzzier all the time, because offloads happen and get supported in mac80211.
> So if you have offloads for header conversion and only get some reordering
> data "out of band", then you have to handle that in the driver. Using mac80211
> doesn't mean you have to use _all_ of it.
Following jobs are done by FW:
1. MAC 802.11 Rx processes except for BA buffering/reordering and AMSDU.
2. Convert 802.11 frame to 802.3 frame.
3. Embedded MAC 802.11 header information to Rx descriptor for driver to do BA buffering/reordering.
If this FW wants to leverage mac80211:
1. Use 802.11 frame:
Driver should restructure 802.11 frame and mac80211 will redo jobs done by FW. I think this does not make sense.
2. Use 802.3 frame:
Driver still needs to do BA buffering/reordering (mac80211 can help with AMSDU with flag IEEE80211_RX_AMSDU,
but cfg80211 also supports function ieee80211_amsdu_to_8023s() to help this job).
If this is the case, it becomes redundant to pass 802.3 frame to kernel stack via mac80211.
So I think cfg80211 will be more suitable for existing FW.
> Originally, mac80211 didn't even have RX_FLAG_8023 after all. But obviously
> adding something like that also requires more upstream engagement :)
>
Yes, we requested 802.3 fast forwarding of mac80211 due to our previous fully Rx offload FW with very powerful WiFi SoC.
> I think the question is about the design, but I also think the differences in the
> association process are much more fundamental, and you _don't_ (seem to)
> handle that in the way mac80211 does/expects, though you also don't seem to
> handle it in the way most other full-MAC devices do (which [can] offload even
> BSS selection.)
>
FW only supports add station command for AP mode. Association command is used to request and add client station to FW.
FW will help to connect to AP and reply result to driver.
This is another reason that we need to use cfg80211 instead of mac80211. For mac80211, management frames are passed
through ieee80211_ops.tx and station is added via ieee80211_ops.sta_add.
This way can't work with FW for client mode, FW can't not be bypassed for association process for client mode.
> The thing I want you to understand is the relative architecture and how your
> work fits into this. I'm not telling you have to change it right now or do this
> work differently, I just want to make sure you actually understand it. The above
> argument goes some way, showing you've actually looked at the differences
> mac80211 would imply, where before I felt you were pretty much handwaving
> it away as if irrelevant to the discussion.
>
> johannes
Thanks for your comments and suggestions. I wonder can I prepare patch v10 to let this patch be accepted?
David
next prev parent reply other threads:[~2024-04-11 7:57 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 2:00 [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme David Lin
2024-03-06 2:00 ` [PATCH v9 1/2] wifi: mwifiex: add host mlme for client mode David Lin
2024-03-16 0:00 ` Brian Norris
2024-03-18 2:00 ` [EXT] " David Lin
2024-03-18 11:41 ` Francesco Dolcini
2024-03-19 1:36 ` [EXT] " David Lin
2024-03-06 2:00 ` [PATCH v9 2/2] wifi: mwifiex: add host mlme for AP mode David Lin
2024-03-16 0:45 ` Brian Norris
2024-03-18 2:04 ` [EXT] " David Lin
2024-04-18 3:37 ` David Lin
2024-03-15 9:49 ` [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme Francesco Dolcini
2024-03-15 23:59 ` Brian Norris
2024-03-18 11:28 ` Francesco Dolcini
2024-03-19 10:33 ` Kalle Valo
2024-03-20 21:06 ` Brian Norris
2024-03-16 0:49 ` Brian Norris
2024-03-19 12:12 ` Johannes Berg
2024-03-20 0:59 ` [EXT] " David Lin
2024-03-20 1:10 ` David Lin
2024-03-20 9:12 ` Johannes Berg
2024-03-20 21:50 ` Brian Norris
2024-03-21 4:07 ` David Lin
2024-03-23 1:06 ` Brian Norris
2024-03-25 16:15 ` Johannes Berg
2024-03-29 10:06 ` David Lin
2024-04-02 17:38 ` Brian Norris
2024-04-10 7:30 ` David Lin
2024-04-10 7:55 ` Johannes Berg
2024-04-10 10:33 ` David Lin
2024-04-10 17:56 ` Johannes Berg
2024-04-11 7:57 ` David Lin [this message]
2024-04-11 8:02 ` Johannes Berg
2024-04-10 7:52 ` Johannes Berg
2024-03-25 15:58 ` Johannes Berg
2024-03-29 9:58 ` David Lin
2024-03-18 9:24 ` Kalle Valo
2024-03-19 1:40 ` [EXT] " David Lin
2024-03-20 21:28 ` Brian Norris
2024-03-21 2:14 ` [EXT] " David Lin
2024-03-16 0:07 ` Brian Norris
2024-03-18 2:20 ` [EXT] " David Lin
2024-03-18 11:45 ` Francesco Dolcini
2024-03-20 21:13 ` Brian Norris
2024-03-21 2:12 ` David Lin
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=DU0PR04MB9636AF728C818073435A0E90D1052@DU0PR04MB9636.eurprd04.prod.outlook.com \
--to=yu-hao.lin@nxp.com \
--cc=briannorris@chromium.org \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=johannes@sipsolutions.net \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rafael.beims@toradex.com \
--cc=tsung-hsien.hsieh@nxp.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 read-only IMAP folder(s) and NNTP newsgroup(s).