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
