Date: Sat, 21 Sep 2013 11:41:09 +0800 From: Chenchong Qin <qinchenchong@gmail.com> To: Sean Bruno <sbruno@freebsd.org> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: Chenchong's work on net80211_ratectl Message-ID: <CAFnsE3d53p8OQoFFP_82qTNLY3yiAqLaf-8caM24ba_-mHgLYA@mail.gmail.com> In-Reply-To: <1379733007.2623.0.camel@localhost> 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> <CAJ-VmonrxRNRX1NzzboJOy0Y0oct5m7q_rcmB=WQiiA57GGXoA@mail.gmail.com> <CAFnsE3eghw-b1iiA_dU7JfnToNTn=4ZeQ8MqeNJ3xaTopGayRg@mail.gmail.com> <CAFnsE3e3f4fdEV_P7n9caJBcbdSDbDnd3aWP=5zDWUGPvqArVw@mail.gmail.com> <1379693639.2625.0.camel@localhost> <CAFnsE3feZ9JRV8a6oHN9jaYpENZye6RAiELuYsAC0Opygo8juA@mail.gmail.com> <1379733007.2623.0.camel@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! Thanks for your reminder! I've posted it to my project page<https://wiki.freebsd.org/SummerOfCode2013/80211RateControl80211nExtensions>. You can now download it from the "Code" section in the bottom. Thanks again! Chenchong On Sat, Sep 21, 2013 at 11:10 AM, Sean Bruno <sean_bruno@yahoo.com> wrote: > There was no .tar.gz file attached to the email. It was probably > stripped by freebsd.org. > > You'll probably need to post it somewhere for us to download. > > Sean > > On Sat, 2013-09-21 at 08:08 +0800, Chenchong Qin wrote: > > Hi! > > > > > > It's in the .tar.gz file attached in last mail. > > > > > > Thanks! > > > > > > Chenchong > > > > > > On Sat, Sep 21, 2013 at 12:13 AM, Sean Bruno <sean_bruno@yahoo.com> > > wrote: > > > > > > On Fri, 2013-09-20 at 11:06 +0800, Chenchong Qin wrote: > > > Hi! > > > > > > Here is the final version and some output from ifconfig and > > sysctl. > > > > > > Thanks! > > > > > > Chenchong > > > > > > > I didn't see anything attached to this message that looks like > > a patch. > > Where should I go to try out your changes? > > > > sean > > > > > > > > > > On Thu, Sep 19, 2013 at 11:09 AM, Chenchong Qin > > <qinchenchong@gmail.com>wrote: > > > > > > > OK! > > > > > > > > I'll post it later. :) > > > > > > > > Thanks! > > > > > > > > Chenchong > > > > > > > > > > > > On Thu, Sep 19, 2013 at 9:38 AM, Adrian Chadd > > <adrian@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@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 > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > _______________________________________________ > > > freebsd-wireless@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > > > To unsubscribe, send any mail to > > "freebsd-wireless-unsubscribe@freebsd.org" > > > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFnsE3d53p8OQoFFP_82qTNLY3yiAqLaf-8caM24ba_-mHgLYA>