Chenchong's work on net80211_ratectl

[Chenchong Qin]

Hi!

Yes!

Here is a fresh debug log.

@adrian you may received many copies of this message because I got the
"Message body too large" limit of freebsd-wireless list. So I compress the
log file and re-send it. Sorry to be confused. :)

Thanks!

Chenchong


On Mon, Sep 16, 2013 at 4:40 PM, Adrian Chadd <adrian at freebsd.org> wrote:

> Sweet!
>
> Does this work on your AR9227? Can you provide some example output?
>
>
> -a
>
>
> On 14 September 2013 21:08, Chenchong Qin <qinchenchong at gmail.com> wrote:
>
>> Hi!
>>
>> Yes, a call to ieee80211_ratectl_rc_info_set() is needed. To make other
>> drivers work, the __init__ and __findrate__ parts also need to be adapted.
>> When initialize the ratectl state, a cap flag must be properly set and
>> feed to ieee80211_ratectl_init().  __findrate__ part should be repalced
>> with our
>> ieee80211_ratectl_rates().
>>
>> I've added  ieee80211_ratectl_rc_info_get() to be used to get the
>> ieee80211_rc_info. If found the tag, use it; if not, add a new one and use
>> it. Then we don't
>> need to free it explicitly (the tag is freed when associated mbuf is
>> freed) and this interface is unified to both __findrate__ and
>> __complete__.
>>
>> Thanks!
>>
>> Chenchong
>>
>>
>> On Sat, Sep 14, 2013 at 11:21 PM, Adrian Chadd <adrian at freebsd.org>wrote:
>>
>>> Ah, cool! I see you've only just made the other drivers compile; what's
>>> required to make them work? i guess a call
>>> to ieee80211_ratectl_rc_info_set() ?
>>>
>>> Maybe you should add a ieee80211_ratectl_rc_info_set_mbuf() helper that
>>> does the "lookup tag; if one exists use it else use a temporary one" code
>>> that you put in if_ath.c, if_ath_tx.c.
>>>
>>> Other than that, this is looking very good! thankyou!
>>>
>>>
>>> -adrian
>>>
>>>
>>>
>>> On 13 September 2013 20:52, Chenchong Qin <qinchenchong at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> Here is latest update. Per-device ratectl statistics is implemented in
>>>> ath and attached when ath is attaching.
>>>>
>>>> Thanks!
>>>>
>>>> Chenchong
>>>>
>>>>
>>>> On Sat, Sep 14, 2013 at 3:37 AM, Adrian Chadd <adrian at freebsd.org>wrote:
>>>>
>>>>> Sweet, thanks!
>>>>>
>>>>>
>>>>>
>>>>> -adrian
>>>>>
>>>>>
>>>>>
>>>>> On 13 September 2013 09:11, Chenchong Qin <qinchenchong at gmail.com>wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> Here is some updates.
>>>>>>
>>>>>> Another member is added to ieee80211_rc_info to record value of the
>>>>>> maximum aggregate size. Then, in aggregation scenario, ratectl algo can
>>>>>> inform aggregation selection code of proper maximum aggregate size.
>>>>>>
>>>>>> Per-vap ratectl statistics is exported through sysctl. When
>>>>>> ieee80211_ratectl_init() is called, this statistics api is attached. It's
>>>>>> convenient to implement the per-device api -- just traverse the vap list
>>>>>> and call per-vap api for each vap. But, we know that ratectl of net80211
>>>>>> provides service to vap-granularity object, not to device directly. So, is
>>>>>> it more suitable to implement the per-device api in device driver (i.e.
>>>>>> attach per-device api when attaching the device)?
>>>>>>
>>>>>> Code will be posted later.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Chenchong
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 12, 2013 at 2:05 AM, Adrian Chadd <adrian at freebsd.org>wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> For now, yes, you have to assume that you won't always get a
>>>>>>> response for a rate lookup. The buffer may be sent with NOACK set, it may
>>>>>>> be deleted during a channel change or scan, etc.
>>>>>>>
>>>>>>> And yes - the rate control lookup stuff for aggregate frames is a
>>>>>>> bit messy. It would be nice for the rate control code to return the rate
>>>>>>> _and_ the maximum aggregate size, in case the aggregation selection wants
>>>>>>> to cap how long frames are at the given choice.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11 September 2013 10:29, Chenchong Qin <qinchenchong at gmail.com>wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I've added some aggregation support here!
>>>>>>>>
>>>>>>>> At first I intend to pass subframe informations(nframes,
>>>>>>>> per-subframe length etc.)
>>>>>>>> to the ratectl api. But it seems to be a paradox that rate lookup
>>>>>>>> must be performed
>>>>>>>> before the ampdu is formed (aggregation limit based on the rate
>>>>>>>> control decision
>>>>>>>> is need) and subframe informations can be obtain only after the
>>>>>>>> ampdu is formed.
>>>>>>>> So, I add a new ieee80211_rc_info flag to ieee80211_ratectl to let
>>>>>>>> it distinguish
>>>>>>>> aggregation and non-aggregation scenarios. If rate lookup is called
>>>>>>>> in an aggregation
>>>>>>>> scenario, this flag is set. Then, ratectl algo knows that it's now
>>>>>>>> finding rates for an
>>>>>>>> ampdu and the framelen which records len of the first frame can be
>>>>>>>> ignored. When
>>>>>>>> it comes to complete period, tx status that shows number of
>>>>>>>> subframes been sent
>>>>>>>> and number of subframes been successfully received is passed to the
>>>>>>>> ratectl api.
>>>>>>>>
>>>>>>>> I also get a question here - whether one tx that doesn't perform
>>>>>>>> rate lookup will call
>>>>>>>> the complete procedure?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Chenchong
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Sep 8, 2013 at 11:18 PM, Chenchong Qin <
>>>>>>>> qinchenchong at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> I've added the common ratectl state as an mbuf tag!
>>>>>>>>>
>>>>>>>>> After days of frustration (compile errors, boot failed, kernel
>>>>>>>>> panics, suddenly kernel freezing...), it seems that ath now can use
>>>>>>>>> 11n-aware net80211 ratectl api to do rate control. Attachment[0] is the
>>>>>>>>> diff of modifications to dev/ath. Changes to net80211 is minor this time.
>>>>>>>>> Just add some debug msgs to it. Please reference my gsoc svn repo<https://svnweb.freebsd.org/socsvn/soc2013/ccqin/head/>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> It's worth mentioning that sometimes the kernel will "freezing"
>>>>>>>>> (it looks like all things stop working, screen is freezing, keyboard and
>>>>>>>>> mouse are not responding) after wireless stuff start working for a while.
>>>>>>>>> At first, I consider it caused by my modification to ath. But this strange
>>>>>>>>> thing can also happen in a head kernel (r255382). Attachment[1] is some
>>>>>>>>> useful messages just before it happens. By the way, I use a AR9227 device.
>>>>>>>>>
>>>>>>>>> And, I found that, for aggregation scenario, ath gathers tx
>>>>>>>>> information and update the ratectl states. So, what we can do to net80211
>>>>>>>>> to let it support aggregation?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Chenchong
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Sep 3, 2013 at 9:29 AM, Chenchong Qin <
>>>>>>>>> qinchenchong at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> OK!
>>>>>>>>>>
>>>>>>>>>> Thanks! :-)
>>>>>>>>>>
>>>>>>>>>> Chenchong
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Sep 3, 2013 at 1:56 AM, Adrian Chadd <adrian at freebsd.org>wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi!
>>>>>>>>>>>
>>>>>>>>>>> You can declare an mbuf tag and use that. Look at M_TXCB in
>>>>>>>>>>> net80211 and how mbuf tags are added.
>>>>>>>>>>>
>>>>>>>>>>> I've long thought about adding a net80211 mbuf tag to represent
>>>>>>>>>>> -all- of the tx related state - TX callback, rate control, rate completion,
>>>>>>>>>>> aggregation state, retry count, etc. That way all the drivers can use it.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -adrian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>