Chenchong's work on net80211_ratectl

[Chenchong Qin]

Hi!

Here is the final version and some output from ifconfig and sysctl.

Thanks!

Chenchong


On Thu, Sep 19, 2013 at 11:09 AM, Chenchong Qin <qinchenchong at gmail.com>wrote:

> OK!
>
> I'll post it later. :)
>
> Thanks!
>
> Chenchong
>
>
> On Thu, Sep 19, 2013 at 9:38 AM, Adrian Chadd <adrian at freebsd.org> wrote:
>
>> Sweet, thanks!
>>
>> Please post the final and some sample output from ifconfig and sysctl
>> somewhere so we can take a more detailed look.
>>
>> I'll be travelling over the next few days; I'll try to get it all
>> finalised later this month.
>>
>> Thanks again! Great work!
>>
>>
>> -adiran
>>
>>
>>
>> On 16 September 2013 02:32, Chenchong Qin <qinchenchong at gmail.com> wrote:
>>
>>> Hi!
>>>
>>> In this update, I update ieee80211_sample and complete
>>> ieee80211_ratectl_none templete.
>>>
>>> * rename ieee80211_rc_sample* to ieee80211_sample*. this seems to be
>>> more harmonious.
>>> * modify ieee80211_sample to let it use the latest net80211-ratectl
>>> features.
>>> * fix some errors in ieee80211_sample.
>>> * complete the ieee80211_ratectl_none templete with newly added
>>> net80211-ratectl functions.
>>>
>>> You will need to add wlan_sample to sys/conf/files to make
>>> ieee80211_sample compiled.
>>>
>>> Thanks!
>>>
>>> Chenchong
>>>
>>>
>>> On Mon, Sep 16, 2013 at 5:08 PM, Chenchong Qin <qinchenchong at gmail.com>wrote:
>>>
>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>