Setting per-frame tx rate for frames injected in raw tx mode

[Michal Kazior]

On 17 May 2016 at 09:14, Raj Joshi <rajjoshi at comp.nus.edu.sg> wrote:
> I see.. So the RA is implemented in firmware and is closed source.
> Also it is unclear if the driver (ath10k) has implemented an API for
> it.
>
> Your idea sounds similar to how it is working for me in ath9k - in the
> file net/mac80211/tx.c, the HT rate information from the radiotap
> header is parsed and set in the struct ieee80211_tx_info (see the
> method ieee80211_parse_tx_radiotap()). A recent commit [1] also added
> parsing for VHT information from radiotap. This seems to be a standard
> way of doing it and it seems to work with "d-link dir-860l rev b1
> running OpenWrt trunk and mt76 driver" as the commit description
> mentions. However with ath10k, the rate from this tx_info seems to be
> not honored :(
>
> But I believe there should be some way of fixing rate settings from
> upper layers of the pipeline. iw lets us do manual bitrate
> configuration [2] for ath10k which works as expected. But this only
> helps in setting of rate per-session. I am still finding answers to
> the following questions:
> 1) What is it that iw does that it manages to get the manual bitrate
> configuration?

It ends up calling driver specific set_bitrate_mask, which is
ath10k_mac_op_set_bitrate_mask() for ath10k. If the bitrate mask is a
single rate (instead of an actual mask/set) driver sends a set of
commands to firmware to force fixed-rate.


> 2) How does it ask the firmware to not do any RA and always honor the
> set rate? Basically how does it override the default RA?

It sends a few per-interface commands to firmware, see
ath10k_mac_set_fixed_rate_params().

Do note this refers to unicast. I think multicast needs a different knob.


> 3) Can we do the same on a per-packet basis?

As it is now there's no easy way to do this.

WMI commands per se don't have any synchronization to them. A few of
them produce feedback events (vdev_start, ping) so you could probably
use them to make sure, e.g. fixed-rate commands were processed before
you submit Tx. You'd also need to flush to avoid changing rate for
frames that are still in Tx ring. I'm not sure how fast that'll be.


Michał