From owner-freebsd-wireless@FreeBSD.ORG Fri Sep 20 03:06:10 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 86A49D72; Fri, 20 Sep 2013 03:06:10 +0000 (UTC) (envelope-from qinchenchong@gmail.com) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00627290B; Fri, 20 Sep 2013 03:06:09 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id cz12so7465220veb.18 for ; Thu, 19 Sep 2013 20:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Oy/RpRcWxJHPtpoTyVVLSQ+1/rq+7bDJZ8w7f1ih/Oc=; b=LdzgiotLukZdRqw/QGuycgba8QN9msQtGTvvlhkQRy9Im59HAgxaBJHqvz5zy0mGhS L+95yOO7Y2/dMiEvfdNLH6EXU33Mf1mzQS1LWmR+edNTEjCbAJQdjUB/KdGJLxCvrG9v UkkZi9NnT0CBROoVoX5vVcCk0zsSo/Ya58YzqUrxzzz0rQsdw6l7yj4+ty06Ls6oEA9H RxZ4ndDEjrjTjP5OCaMrVxHLtvPO6qTo3CBX4AB9iX2Zi/OF6pGNAPOttJVbtFvnRWpV cbVoQBBKJCGSPRxrNnpPfnnZwnqY+IVvhkLIjLBiHtvpC8QUlHapDndOUfPXSxn8MZb2 io0A== MIME-Version: 1.0 X-Received: by 10.58.46.229 with SMTP id y5mr4095265vem.15.1379646368723; Thu, 19 Sep 2013 20:06:08 -0700 (PDT) Received: by 10.220.182.68 with HTTP; Thu, 19 Sep 2013 20:06:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Sep 2013 11:06:08 +0800 Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Chenchong Qin To: Adrian Chadd Content-Type: multipart/mixed; boundary=089e0112d006b9872d04e6c7f31d 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: Fri, 20 Sep 2013 03:06:10 -0000 --089e0112d006b9872d04e6c7f31d Content-Type: text/plain; charset=ISO-8859-1 Hi! Here is the final version and some output from ifconfig and sysctl. Thanks! Chenchong On Thu, Sep 19, 2013 at 11:09 AM, Chenchong Qin wrote: > OK! > > I'll post it later. :) > > Thanks! > > Chenchong > > > On Thu, Sep 19, 2013 at 9:38 AM, Adrian Chadd 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 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 < >>>>>>>>>>> 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 . >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --089e0112d006b9872d04e6c7f31d--