Chenchong's work on net80211_ratectl

[Chenchong Qin]

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