linux-kernel - Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7af985e13d3254de73f9d68e1ad4ad1f81b5fd59.camel@sipsolutions.net>
Date: Wed, 10 Apr 2024 19:56:44 +0200
From: Johannes Berg <johannes@...solutions.net>
To: David Lin <yu-hao.lin@....com>, Brian Norris <briannorris@...omium.org>
Cc: Francesco Dolcini <francesco@...cini.it>, "kvalo@...nel.org"
 <kvalo@...nel.org>, "linux-wireless@...r.kernel.org"
 <linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, Pete Hsieh <tsung-hsien.hsieh@....com>, 
 "rafael.beims" <rafael.beims@...adex.com>, Francesco Dolcini
 <francesco.dolcini@...adex.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.
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