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 <qinchench...@gmail.com> 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"
