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
