From owner-freebsd-wireless@FreeBSD.ORG Fri Sep 20 12:37:00 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 1C4549DC for ; Fri, 20 Sep 2013 12:37:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 772072466 for ; Fri, 20 Sep 2013 12:36:59 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id w62so433901wes.32 for ; Fri, 20 Sep 2013 05:36:58 -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=fEnhmXcfDPRs8pgXUzVkahW2FG/cnH70iOca21F4W6k=; b=PLM4dMSRwz5ue1yT+EoYUdi5vQDpZgTFsLyu1rp0x4EZha8D7/0g+5BM/caN0AKmeJ uycmER4bbdIpTiQIqNv9XMwavOsYaW7lJqdOrGHK4FFr2grGJOqw3GrKfWjTWCe72htZ K5VCw+CO92/ZaiPK0oFfeNV7h3AMSbabCOfMNXkazm7lSAauM2fPJehAnLh9Jm+pzReu NGrHeFNIDOJESWROlwkVNSZk/P5mlpJkWT4SlqjkkiUVpOJa7TqT7K5XKgXkA56uDm3R q1piJIaT58tQJ0kowQQ5cdEs9YATEKlckLUjNTVy3CGmMU71G6sYoqrAKXIXKp4f5OSs 2FiA== MIME-Version: 1.0 X-Received: by 10.180.10.136 with SMTP id i8mr2639554wib.46.1379680617791; Fri, 20 Sep 2013 05:36:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Fri, 20 Sep 2013 05:36:56 -0700 (PDT) Received: by 10.216.73.133 with HTTP; Fri, 20 Sep 2013 05:36:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Sep 2013 05:36:56 -0700 X-Google-Sender-Auth: tETvu7fJpFlvhNP16S0NAHFv2kg 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: Fri, 20 Sep 2013 12:37:00 -0000 Cool! I'll check it out once I have finished traveling. Thanks for all your hard work! Adrian On Sep 19, 2013 8:06 PM, "Chenchong Qin" wrote: > 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 < >>>>>>>>>>> adrian@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@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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >