Received-SPF: pass (google.com: domain of linux-wireless+bounces-6129-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <7af985e13d3254de73f9d68e1ad4ad1f81b5fd59.camel@sipsolutions.net>
Subject: Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support
 host mlme
From: Johannes Berg <johannes@sipsolutions.net>
To: David Lin <yu-hao.lin@nxp.com>, 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>
Date: Wed, 10 Apr 2024 19:56:44 +0200
In-Reply-To: <DU0PR04MB96366A0E1FEBD7440F7536D0D1062@DU0PR04MB9636.eurprd04.prod.outlook.com>
References: <ZfTspRKFgrO9xCTH@google.com>
	 <969e95ccc4a1d35b45212b7fcb536ee90995e3b5.camel@sipsolutions.net>
	 <PA4PR04MB9638D253189D6DD330B198B2D1332@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <PA4PR04MB9638BE73DDBCE1CE8AA32BA8D1332@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <b2d9a7ef53c5ab4212617e8edf202bbafe52e2f8.camel@sipsolutions.net>
	 <ZftaJEIeNfV7YrVo@google.com>
	 <PA4PR04MB9638F5037D1AB9BCF51CC9D9D1322@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <Zf4rDifM6bLuqpX2@google.com>
	 <4e5f3741819e457c5c79d825c6520cb9ee531b95.camel@sipsolutions.net>
	 <PA4PR04MB96386917877832602F221282D13A2@PA4PR04MB9638.eurprd04.prod.outlook.com>
	 <ZgxCngq_Rguc4qs8@google.com>
	 <DU0PR04MB96365F2B6AFD856655D6A66CD1062@DU0PR04MB9636.eurprd04.prod.outlook.com>
	 <5cf6b243c3967cd5a630f8f8e5bf17f7c9010f01.camel@sipsolutions.net>
	 <DU0PR04MB96366A0E1FEBD7440F7536D0D1062@DU0PR04MB9636.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Wed, 2024-04-10 at 10:33 +0000, David Lin wrote:
>=20
>=20
> 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 h=
ost driver (Mwifiex) due to memory consideration. We used to work on a driv=
er that uses RX_FLAG_8023. It was on an older Wi-Fi part which has more mem=
ory and powerful processor. But with this chip buffer required for reorderi=
ng doesn=E2=80=99t fit FW memory.=20
>=20
> Ampdu reordering needs MAC 802.11 header, FW keeps the MAC header in pack=
et descriptor since packet already 802.3 when arrive at driver. As packet d=
escriptor only accessible in the driver, Mwifiex handles the reordering ins=
tead of using mac80211 reordering.=20
>=20
> With current FW design, to apply mac802.11 we either change FW to pass pa=
cket in 802.11 format or driver needs to do the conversion back to 802.11 (=
which I think doesn=E2=80=99t make sense)=20
>=20
> Given existing FW design, we think it=E2=80=99s difficult to apply mac802=
11.

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.
Originally, mac80211 didn't even have RX_FLAG_8023 after all. But
obviously adding something like that also requires more upstream
engagement :)

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.)

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