Date: Wed, 11 Sep 2013 11:05:44 -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-Vmok3dAHiwbeyEU6B4oWm=n36ME2yyGE69twjdEygr8iZSw@mail.gmail.com> In-Reply-To: <CAFnsE3e1r6Ah5SSrqnrxoqXMRm3yCaUxCjSD90epWQJEZU-pzw@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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-Vmok3dAHiwbeyEU6B4oWm=n36ME2yyGE69twjdEygr8iZSw>