OK! I'll post it later. :)
Thanks! Chenchong On Thu, Sep 19, 2013 at 9:38 AM, Adrian Chadd <adr...@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 <qinchench...@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 <qinchench...@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 <adr...@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 <qinchench...@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 <adr...@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 <qinchench...@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 <adr...@freebsd.org>wrote: >>>>>>> >>>>>>>> Sweet, thanks! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -adrian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 13 September 2013 09:11, Chenchong Qin >>>>>>>> <qinchench...@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 >>>>>>>>> <adr...@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 <qinchench...@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 < >>>>>>>>>>> qinchench...@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 < >>>>>>>>>>>> qinchench...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> OK! >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Chenchong >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Sep 3, 2013 at 1:56 AM, Adrian Chadd < >>>>>>>>>>>>> adr...@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-unsubscr...@freebsd.org"