Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Sep 2013 18:38:08 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Chenchong Qin <qinchenchong@gmail.com>
Cc:        "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org>
Subject:   Re: Chenchong's work on net80211_ratectl
Message-ID:  <CAJ-VmonrxRNRX1NzzboJOy0Y0oct5m7q_rcmB=WQiiA57GGXoA@mail.gmail.com>
In-Reply-To: <CAFnsE3e6oihNpH-mA%2BG36JvwFNeJyJh_FGnsT_MYfpGcQ7GXHQ@mail.gmail.com>
References:  <CAFnsE3dYdPf5yGTFH683Q1Zh0mc-g%2B_YtCTraNNt28z2vBoSKw@mail.gmail.com> <CAJ-Vmom4sY7jcNwWmJkrDwfWjsok2fk8UEwTi5A=egj1JyerLw@mail.gmail.com> <CAFnsE3cyg=msBfQqqKUMmLABSL=j24VoMBwbBjxQ6b7Dyy7Mqg@mail.gmail.com> <CAJ-Vmo=k8NddAYyAJCkx4eOaA_8XsSxg6uKrdddx%2BgmeT%2BX9KA@mail.gmail.com> <CAFnsE3eaOyRcO3LXSi3L=jbzpyMv5Nt_jRGKt_mmA0WV-EV5vA@mail.gmail.com> <CAJ-VmokdxLhK5x6kO=jJzk-dv61EDK-ZgmndOimoyWWf76HiZA@mail.gmail.com> <CAJ-VmonMjR5iVTMVN9532d%2BPqOXWNUoZvxPtQir5h=yGxU-XdQ@mail.gmail.com> <CAFnsE3d9nG-X2b=z1srKfTtpxC3w5L%2B6Hg3TbOnAQrJN%2Bt19GA@mail.gmail.com> <CAJ-VmokF6hPtg9FoEdeJXLLaZRNhzd=nr_o6nHE%2BjYiQKTg3zQ@mail.gmail.com> <CAFnsE3eMwX-GiRzJt8jk4r9mxwSAQkcrDwk%2BnWVG7q6dabeA3A@mail.gmail.com> <CAJ-Vmo=mzvS0UBC7fGx2t501%2Bfioi4DJcw8qobOpbYOUiraqGg@mail.gmail.com> <CAFnsE3df=1WEuLZh5355v_K2eBgcuBbpoza74Y-5vvNupBz22A@mail.gmail.com> <CAJ-VmokyXwkKLdsJw74bux7G5EJSRvFhugTcLR9BgXfw4ysYRg@mail.gmail.com> <CAJ-VmokU=ZXysjZfAJ-REZL7kwg-_Z-LeAKca7AefONW_O1E5A@mail.gmail.com> <CAFnsE3cS_2Ad1geQQ0UB4doEgqVfhNBMi6j4fCRpFgQqcu2kJw@mail.gmail.com> <CAFnsE3eMrwpo=hcFb9XfpLL53Ppso%2B%2BXTBfpieP8FGejAKW1_w@mail.gmail.com> <CAJ-Vmo=s=0u7VO00vgzxmR7bE4aTtMrshZ3j5F312dya284V1g@mail.gmail.com> <CAFnsE3c%2BOg_2hVXO3zU7gmY4xFQjnxbv=ehJm=pbbpLJcgwJrQ@mail.gmail.com> <CAJ-Vmo=D3BNhhSn9D3x6hBry=fDecOd7BwttQ5Yw2iUKGDBN3w@mail.gmail.com> <CAFnsE3dw5bOyVRqMb9K3ME%2BHoDL61-e_XNJjjt_nRTaY=4dnhw@mail.gmail.com> <CAJ-Vmo=0tkTKQnOjrmYKqWqC%2B_nnFLqimdp06STETxLsFgxKxQ@mail.gmail.com> <CAFnsE3dm27483GVp4PRiwk=sxagT7NXQz4fmyOpth2zpCM2MwQ@mail.gmail.com> <CAFnsE3fvpjCXEC1gN46VXfPdeXG5RSVzNiJkZJiQ6xSYQFb89g@mail.gmail.com> <CAFnsE3e1r6Ah5SSrqnrxoqXMRm3yCaUxCjSD90epWQJEZU-pzw@mail.gmail.com> <CAJ-Vmok3dAHiwbeyEU6B4oWm=n36ME2yyGE69twjdEygr8iZSw@mail.gmail.com> <CAFnsE3dxXr05%2Bv7F2hF7Qauoz-qqDzxkXiZrhUAtaxf0ObNhDg@mail.gmail.com> <CAJ-Vmo=Se2JziV8D2PYNgxmZro-3JRpp3ZsRkTTWvUQ0YigRPw@mail.gmail.com> <CAFnsE3cFFHxOwLY2OFxhCUAM-Bg2zZvjrC8LMx17N-dfND74KQ@mail.gmail.com> <CAJ-Vmonbj9KE_oM6xXPnKksA1u=9FH41e4_bQE1cgwebydZgtA@mail.gmail.com> <CAFnsE3fnApV_=FNggEuhy1B=idXLxgymqqmJ=9XXrjspLoe%2BWA@mail.gmail.com> <CAJ-VmomSSf9uTkOZDv=5SHSvp-ydUFPQZcCRzjBfognP_NMWAg@mail.gmail.com> <CAFnsE3dv250HYaCiyezT3zmO1E-yj9fcL4nzxqnMyjuQuON2aw@mail.gmail.com> <CAFnsE3e6oihNpH-mA%2BG36JvwFNeJyJh_FGnsT_MYfpGcQ7GXHQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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@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@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@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@freebsd.org>wrote:
>>>>>>
>>>>>>> Sweet, thanks!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -adrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13 September 2013 09:11, Chenchong Qin <qinchenchong@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@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@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@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@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> OK!
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks! :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Chenchong
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Sep 3, 2013 at 1:56 AM, Adrian Chadd <
>>>>>>>>>>>> adrian@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonrxRNRX1NzzboJOy0Y0oct5m7q_rcmB=WQiiA57GGXoA>