Frame scheduling support

[CodeFetch]

I'd like to implement 802.11s MCCA, but the only driver that would be supported is ath9k, which is a bit outdated. That's no fun. Is there a release-on-beacon queue or something in ath10k chipsets I can use to schedule transmitting? I assume it is as AirMax has TDMA support... What's the estimated cost to get this supported in ath10k-ct?

[greearb]

I am not familiar with MCCA. Can you let me know some details of what API you think you would need? Maybe pause/un-pause specific TIDs on specific peers? What timing requirements would that have?

[CodeFetch]

The big problem in MCCA is the synchronization. 802.11s needs to do clock drift calculations using the other node's beacon timestamps and there is still the "fastest clock problem" which can only be easily mitigated in multi-hop setups by using a reference clock (e.g. GPS). I assume ath10k can't "kill frames in flight" thus before handing the frames to ath10k the estimated duration of the frame transmission must be calculated in mac80211 to not overrun the slot time. The timing requirements are harsh. It should never be > 20 usecs (< 10 usecs would be great). As I assume the ath10k RISC processor is not that powerful (besides I was told it is powerful) the naive approach I think of is setting the TBTT-register from mac80211 and putting the frames in the beacon queue.

The initial goal should not be to support MCCA, because of the complex modifications of mac80211, but a simple TDMA mode in a lab environment. If the timing requirements are met the way is free for MCCA and funding should be no problem.

[CodeFetch]

I see you have implemented set_tsf() and get_tsf() which also shifts the TBTT. The code says:

     * Given tsf argument is entire TSF value, but firmware accepts
     * only TSF offset to current TSF.
     *
     * get_tsf function is used to get offset value, however since
     * ath10k_get_tsf is not implemented properly, it will return 0 always.
     * Luckily all the caller functions to set_tsf, as of now, also rely on
     * get_tsf function to get entire tsf value such get_tsf() + tsf_delta,
     * final tsf offset value to firmware will be arithmetically correct.

For mandatory 802.11s mesh synchronization it needs to be possible to set a value in reference to the RX MAC timestamp say an absolute value. Does that mean beacon collision avoidance does not work at the moment?

Edit: Just looked at kvalo's source code... set_- and get_tsf functions were dropped and replaced with offset_tsf. So it seems he didn't find a way to set an absolute TSF value either.

[CodeFetch]

Nevermind! I have just realized that this is where the "fastest clock problem" originates and it has never been implemented correctly open-source. Without absolute TSF values or stations exchanging information about the other station's offsets it's not possible to do a proper drift adjustment and as it is not defined in the standard how to exchange such information, it is not possible to implement a standards conform MCCA implementation. So I'll build a non-conforming version... Thank you for your time!

[greearb]

The ath10k-ct wave-1 firmware can return the full 64-bit tsf in the debugfs fw_stats logic. Looks like I did not do the same thing for wave-2 at this time.