Re: great interest in the net80211 rate control API extension project in the wireless section of FreeBSD's GSoC 2013 idea list
Hi, >From now on, would you mind cc'ing freebsd-wireless@freebsd.org on discussions about this? I'd prefer to have this discussion in public so everyone can benefit! On 16 July 2013 20:28, Chenchong Qin wrote: > Hi! > > I've read your change to ieee80211_[phy amrr] and commited some code to my > soc repo. Cool! > For pre-802.11n, if rts/cts flag is set on retry 0, retries 1, 2, 3 can't be > used. And if rts/cts flag is not set on retry 0, we take it as a > non-protected rate series, rts/cts of retries 1, 2, 3 is useless neither. Right. This is specific to the Atheros hardware that supports this kind of multi-rate retry. > So, for non-11n scenario, I clear rts/cts flag of retries 1, 2, 3 and if > retry 0 enable rts/cts, blank tries 1, 2, 3. Is this logic resonable? Right. Well, what I think it should be is some kind of hardware capability that the chip tells the rate control code when it initialises. Ie; * I support multi-rate retry; * I support RTS for all rate retries (defaulting to the non-11n behaviour of _EITHER_ multi-rate retry + no RTSCTS, _OR_ single rate try + RTS/CTS > As for the 11n stuff for rate control, it seems to happen after lookup of > rates. Functions in if_ath_tx_ht.c, ie. ath_tx_rate_fill_rcflags and > ath_buf_set_rate, are called after ath_tx_do_ratelookup. Are we going to > implement all the same thing in one ieee80211_ratectrl_ functioin, or > sepreate functions? Well, what do you think? You're the one tinkering with this. :) Note that I've done it in a few places; * I do the rate lookup from ath_rate; * I then copy that into an ath_rc_series array; * I then "fix" the rate series up with 11n options - based purely on the negotiated parameters; * I convert the ath_rc_series into the HAL series, turning these options into hardware specific flags. Now, this means: * if it's a HT40 AP and STA, I always transmit HT40 - even though I could in theory choose to transmit HT20; * if the AP/STA support STBC, I always transmit STBC for MCS 0-7, but I in theory could choose not to; * If the AP/STA support short-GI, I always transmit it, even if I may choose not to; * etc. I did that because it's simple. But it may be that we should leave that up to the rate control module. It may decide to try transmitting HT20 only frames even though both sides are HT40. What do you think? -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
Re: great interest in the net80211 rate control API extension project in the wireless section of FreeBSD's GSoC 2013 idea list
Hi! I'm going to cc freebsd-wireless@ because I think it's a good idea to keep the community in the loop with what's needed for the rate control APi improvements. On 26 June 2013 09:46, Chenchong Qin wrote: > Hi, > > First, sorry for not contact you in these days. It's fine! > I've browsed freebsd's wifi stack and the mac80211. After walking through > the whole stack, I found the rate control is done just before the frame's > handoff to hw (as for the case of ath)... Right. It's done like that in all the wifi stacks that you see. > There is a simple rate control api in net80211, but the ath driver also > contains a rate control api and implementations of rate control algorithms. > And, it seems that ath doesn't use net80211's rate control api. So, how we > handle the relationship of these 2 apis? Enable one & disable the other or > something else? The eventual goal is to deprecate the ath_rate stuff and migrate it all to net80211. That way everything can share the same rate control code for all drivers. > Now I'm trying to add multiple rate attempts support to net80211's rate > control api. Whether I should do the rate control in net80211 and disable > the ath's rate control stuff? Well, you don't have to do that just yet. Just look at listing all the extra work that the ath_rate API does and the TX code in if_ath_tx_ht.c does based on the decisions from the rate control code. Once you have a good idea of what's going on, it's then a question of implementing those same features in net80211's rate control code, but making them optional. For example, the first thing I'd do is modify the net80211 rate control code to do multi-rate table stuff, rather than returning a single rate table entry. Support up to say 4 rate table entries. When the driver creates the rate control module instance for use, it will have to say "hey, I support up to 4 rate retries". Some drivers only support one. Some support 2. The AR5210/AR5211 support 1, the AR5212 and later support 4. The next thing I'd do is look at what options are available for each rate. For the AR5212, you can only do RTS/CTS with a single rate attempt. Ie, you can't do multi-rate retry in hardware _and_ RTS/CTS. Thus, with RTS/CTS you have to only do one rate attempt. For the AR5416 and later, you can change the RTS/CTS flags per rate attempt. So you'd have to capture that. That's the really big thing. Once you've implemented that in the net80211 rate control code we can easily smash it into a couple of drivers and test it out. We can then work on 11n stuff _after_ that. 11n isn't that scary; it's just more options. But the really tricky bit is the muti-rate retry scheme. > > Besides, lots of big structs and driver related things that I'm unfamiliar > with make me feel the stuffs are complicated. Do you have some futher > references for me? Not really. I suggest you create a document and note what you've found thus far, so we can _write_ this reference. You've already reviewed it, so it's partially done! Thanks! Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
