On 11/05/2018 12:32 PM, Johannes Berg wrote:
Hi,
Here are several RFC patches providing simple high-level controls of AMSDU/AMPDU
aggregation. The primary purpose of this functionality is an attempt to fill
missing gaps in nl80211 interface for basic WFA certification tests.
I see you don't implement it this way in the driver, but wouldn't it
make more sense to have this as a per-STA (RA) setting? That's really
the granularity it can be done on, I think?
Arguably even per-RA/TID, though that seems a little excessive?
I like the idea of providing this API per peer/tid. And, just allow
peer == -1, tid == -1 or similar to mean 'all' so that you can still set the entire device
to one particular setting w/out having to iterate through all peers if you
don't want to iterate...
We experimented with QCA sigma-dut tool: https://github.com/qca/sigma-dut.
The purpose was to cover basic HT/VHT WFA STA tests for cfg80211 driver
controlled by wpa_supplicant w/o adding any vendor specific commands.
Multiple WFA test parameters (e.g. STBC, NSS, SGI, LDPC) can be configured
by overriding HT/VHT capabilities in wpa_supplicant and applying them on
connect in cfg80211_connect callback. Others (e.g. RTS params) can be
configured using iw tool or NL80211_CMD_SET_WIPHY directly. These patches
implement simpe high-level switches for AMSDU/AMPDU aggregation.
It would be interesting to collect comments/concerns regarding this approach.
Does it make sense to enhance nl80211 in order to cover all the missing pieces
required for WFA certification tests ? Or maybe it makes sense to use
NL80211_TESTMODE subcommands for this kind of testing.
Honestly, I don't really know.
I think other tests, e.g. noack, we used to just have debugfs files for,
and then we got NL80211_CMD_SET_NOACK_MAP (which *is* per TID, btw)
Perhaps if we really don't see any value beyond the testing, keeping it
in debugfs would make sense, until we have more use cases and understand
the granularity we should support?
Clearly this is enough for the testing you refer to, but other use cases
might actually need more fine-grained control (in the future), possibly
down to the RA/TID level?
At least with ath10k, it seems to be a common struggle for AP manufacturers
to do regulatory testing. I would image that is true for other chipsets
as well, so it seems like it might be worth adding to the official API.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
