Chenchong's work on net80211_ratectl

[Adrian Chadd]

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
>>>>
>>>>
>>>
>>
>