Chenchong's work on net80211_ratectl

[Chenchong Qin]

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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20130914-net80211-ratectl-ath.diff
Type: application/octet-stream
Size: 119377 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20130914/004dfac5/attachment-0001.obj>