Chenchong's work on net80211_ratectl

[Chenchong Qin]

Hi!

Attachment is my latest update. In this update, I teach ieee80211_amrr to
return
multiple rates and modify ath to let it use net80211_ratectl.

I realized that 2 tasks must be done before I can test the modified ratectl
api on
my AR9227 device. that is:

1) get a ratectl algo ready to use. ieee80211_amrr is choosed here. I
modified it to
fit the updated net80211_ratectl. That includes making it return multiple
rates and
use a unified ieee80211_rc_info to do the __complete__.

2) modified ath driver to let it use ieee80211_ratectl. We know that ath
uses it's own
rate control code to do the rate decisions and rc flags setups. So
ieee80211_ratectl
need to take over process of rate lookup and other related stuffs.

During my first attempt modifing ieee80211_amrr, I try to make it look
similiar to
ath_amrr. But, latter I found that perhaps we don't need to. As to amrr,
once we get
the first rix, we get the others. So we don't need to record lots of states
like
amn_tx_rate[0|1|2|3]. And, I found that, ath_amrr is quite confused. It
seems that it
return the ratecode as rix. rix should be the ratetable index, right? I've
saw that the rix
is used to index ratetable.

The modifications to ath is really strait forward. I just push
net80211_ratectl into ath
and copy ieee80211_rc_series to bf->bf_state.bfs_rc after we get the rates.

I also add a 48 bytes buf to mbuf (actually to m_hdr). That is where we
store ratectl
state ieee80211_rc_info for a frame. The struct mbuf is so elegant that I
really don't
want to add any thing to it. If you know some other places that is fit to
store the ratectl
state, please let me know. Thanks!

I compiled my latest kernel and tried it. A kernel panic with message "not
mcs" occured.
Perhaps my modifications to ieee80211_amrr caused it. I'll check it.

Thanks!

Chenchong


On Tue, Aug 27, 2013 at 5:02 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> Sweet! Let me know how it goes.
>
>
>
> -adrian
>
>
>
> On 25 August 2013 23:43, Chenchong Qin <qinchenchong at gmail.com> wrote:
>
>> Hi!
>>
>> I struggled to perform changes to all parts that affected by my update to
>> ratectl api
>> and got the customized kernel compiled... I'm now tring to play it on my
>> AR9227 device.
>>
>> Thanks!
>>
>> Chenchong
>>
>>
>> On Sun, Aug 25, 2013 at 10:39 PM, Adrian Chadd <adrian at freebsd.org>wrote:
>>
>>> Hi!
>>>
>>> Have you tried this out with any hardware just yet?
>>>
>>>
>>> -adrian
>>>
>>>
>>>
>>> On 25 August 2013 07:30, Chenchong Qin <qinchenchong at gmail.com> wrote:
>>>
>>>> Hi!
>>>>
>>>> This is the latest update.
>>>>
>>>> * add a simple per vap ratectl statistic tracker and api to update it.
>>>> * port irn_capabilities to irs_capabilities in struct ieee80211_rc_stat.
>>>>   perhaps the capabilities field needs to be within ieee80211_rc_stat as
>>>>   a per vap atrribute. corresponding updates performed.
>>>> * add ieee80211_ratectl_none.h to record common ratectl state.
>>>>
>>>> Thanks!
>>>>
>>>> Chenchong
>>>>
>>>>
>>>> On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin <qinchenchong at gmail.com>wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Here is my latest update. In this update:
>>>>>
>>>>> * add a new struct, ieee80211_ratectl_node. This is the common state
>>>>> that all per node rc
>>>>>   state, i.e. ieee80211_[amrr|sample]_node, should contains it as the
>>>>> first field. It's now used to store
>>>>>   the capabilities. see below.
>>>>> * rename ir_capabilities to irn_capabilities and move it to
>>>>> ieee80211_ratectl_node (it contained in
>>>>>   ieee80211_[amrr|sample]_node). ieee80211_ratectl is readonly, so
>>>>> ir_capabilities can't be set. And,
>>>>>   the capabilities is not a part of rc algo. It seems that it should
>>>>> be put in the per node rc state. Interface
>>>>>   of ieee80211_ratectl_node_init() and its callers  are updated.
>>>>> References to ir_capabilities are also adapted.
>>>>> * add ieee80211_ratectl_[node_is11n|get_rateset] to the ratectl api.
>>>>> rc algoes all need these functions.
>>>>> * change the naming conversion of IEEE80211_RATECTL_FLAG_*.
>>>>> * some errors fixed.
>>>>>
>>>>>
>>>>> On Thu, Aug 15, 2013 at 12:58 AM, Adrian Chadd <adrian at freebsd.org>wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> So yes, we do need to have a generic way of returning that completion
>>>>>> information to the rate control code.
>>>>>>
>>>>>> I'm all for you churning the rate control API to return a struct
>>>>>> ieee80211_rc_info in the complete function and totally just kill arg1/arg2.
>>>>>> That forces us to extend ieee80211_rc_info to be "right" for all the
>>>>>> drivers.
>>>>>>
>>>>>
>>>>> Do you mean drop arg1/arg2 and pass pointer of ieee80211_rc_info to
>>>>> the complete function directly? Or return it
>>>>> when complete function return?
>>>>>
>>>>>
>>>>>> What wifi devices do you have there? It looks like we're almost at
>>>>>> the point where we can start converting a few things to use the modified
>>>>>> rate control API and modules - notably iwn (which won't use the multi-rate
>>>>>> retry stuff to begin with - it works "differently"..) and ath (which will
>>>>>> use the multi-rate retry stuff and the sample rate control module.)
>>>>>>
>>>>>
>>>>> Yeah, I have an AR9227 device at hand.
>>>>>
>>>>> And, I also get a question here. The ieee80211_ratetable doesn't get a
>>>>> rateCode field. So, how we get the
>>>>>  ratecode of the non_ht rate?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chenchong
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20130902-net80211-ratectl.diff
Type: application/octet-stream
Size: 103333 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20130903/ad4c9c59/attachment-0001.obj>