From owner-freebsd-wireless@FreeBSD.ORG Thu Sep 19 01:38:11 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4250F11E for ; Thu, 19 Sep 2013 01:38:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E76E25BB for ; Thu, 19 Sep 2013 01:38:10 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hn9so4918917wib.11 for ; Wed, 18 Sep 2013 18:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OilgoTTrrQTLwJUQfS860LfkjGC+uMxOJnOH5cybh6I=; b=semrWrCIL6wLLLe6sobuYTA9IDAnP1j0NsGVClY3MDAhZkHr/8QsPra/sdtsX867al xYDcKrPhQkguWgWCsTQNqHwzjoboEQn0yLnAdhEVWKP8W+SE6cTfAiuzVPqZee9ZOArb 6eJ8PVeE+mwUi60UQH3BI74XOWq9bwJEynWOoiEpxzDj+p5erBYe/3psxV/bwkfdlvk6 ZT2FKB3DoAZ7dwzhJzPZ/F3gm1kbYdKVSOw7CRUj1CK2SWjT7BOHKyjb48bdu66W6QOF Ocdvo+NXr0+1yCSfyDifSMSP3/ShjlvcD7+kZK/dP8oG1YrFCPeYEHj/0962Z3eDNw8n vwDA== MIME-Version: 1.0 X-Received: by 10.180.93.104 with SMTP id ct8mr9709568wib.0.1379554688988; Wed, 18 Sep 2013 18:38:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Wed, 18 Sep 2013 18:38:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Sep 2013 18:38:08 -0700 X-Google-Sender-Auth: mkvADhlZXBJfkXo66fnkM6ZAEdU Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Adrian Chadd To: Chenchong Qin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 01:38:11 -0000 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 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 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 wrote: >> >>> Sweet! >>> >>> Does this work on your AR9227? Can you provide some example output? >>> >>> >>> -a >>> >>> >>> On 14 September 2013 21:08, Chenchong Qin 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 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 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 wrote: >>>>>> >>>>>>> Sweet, thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> -adrian >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 13 September 2013 09:11, Chenchong Qin 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 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 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 . >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >