From owner-freebsd-wireless@FreeBSD.ORG Mon Sep 16 09:32:22 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 61BFBFBA; Mon, 16 Sep 2013 09:32:22 +0000 (UTC) (envelope-from qinchenchong@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E10712AAD; Mon, 16 Sep 2013 09:32:21 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ia10so2674680vcb.34 for ; Mon, 16 Sep 2013 02:32:21 -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=Uig87NSmdLS1Blg5s2dCLhGoCR+4faLehHIoIOV5QXY=; b=Zy8WOYz6MeTgCeeXobJPWv20CVrxulbPtJZYDaXtZTAxiRHyjvsqsJTsAsgQhvv8M7 +keRcPC5+xKI9Q9Hb5BeJK3vAOECehQ5nmwLJ2wBTVHK+1CTylUgujsYhuLbFL6y+jkO 1OcAksd36rJpyU+tzcCiMRRWNLl0UagU5pl1B9acShQzgMGveBzBVmn5ER4ffiez6wlb DF1g2RBtN3nXrvsXabZ7j5yfXh2Tf1QGd8/JsGV4pNEVeMjpH2NP0hmqwIX4WYzH/FNx vG+wFw2QD66aC06sB4/5nqEues2HECq35xidSzxwm05+LpE4xiUE6bbmqEADPNmQfxn3 0K9g== MIME-Version: 1.0 X-Received: by 10.58.77.65 with SMTP id q1mr7934855vew.8.1379323940881; Mon, 16 Sep 2013 02:32:20 -0700 (PDT) Received: by 10.220.182.68 with HTTP; Mon, 16 Sep 2013 02:32:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 17:32:20 +0800 Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Chenchong Qin To: Adrian Chadd Content-Type: multipart/mixed; boundary=e89a8f6474ed86ff0d04e67ce159 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: Mon, 16 Sep 2013 09:32:22 -0000 --e89a8f6474ed86ff0d04e67ce159 Content-Type: text/plain; charset=ISO-8859-1 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 >>>>>>>>>> > 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --e89a8f6474ed86ff0d04e67ce159--