Chenchong's work on net80211_ratectl

Chenchong Qin qinchenchong at gmail.com
Sat Sep 21 03:41:11 UTC 2013


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 at 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 at 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 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
> >         > >>>>>>>>>>>>>>>
> >         > >>>>>>>>>>>>>>>
> >         > >>>>>>>>>>>>>>
> >         > >>>>>>>>>>>>>
> >         > >>>>>>>>>>>>
> >         > >>>>>>>>>>>
> >         > >>>>>>>>>>
> >         > >>>>>>>>>
> >         > >>>>>>>>
> >         > >>>>>>>
> >         > >>>>>>
> >         > >>>>>
> >         > >>>>
> >         > >>>
> >         > >>
> >         > >
> >
> >         > _______________________________________________
> >         > freebsd-wireless at freebsd.org mailing list
> >         > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> >         > To unsubscribe, send any mail to
> >         "freebsd-wireless-unsubscribe at freebsd.org"
> >
> >
> >
>
>


More information about the freebsd-wireless mailing list