From owner-freebsd-wireless@FreeBSD.ORG Mon Sep 16 09:08:58 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 E1D3FBC6; Mon, 16 Sep 2013 09:08:57 +0000 (UTC) (envelope-from qinchenchong@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 79895293B; Mon, 16 Sep 2013 09:08:57 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so2708141vbh.12 for ; Mon, 16 Sep 2013 02:08:56 -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=qaDzA8GkHoyEPbFwneuRXvxJKO/O6jKKHaFTNuNwJQE=; b=ufRrKKeo7utEj6qJEvwNs7mxf2tlRKFxGHsqLLPls9+fGPHTPsCdbJTJammXQbnLq9 kGDT/44Ql5vePtZUD2+ffGuh9HV+DBEO32CFkyENNqAi5/WdoraSLMI4tQpKo9EgoJQO vtB9Nh4nLCDxiUiFMob8BGNk3S5G+zicSLKBgE9MCjcGPWm+4guv1s9qhJz4AEd+Jch6 mhZ7V5pbf8NyMYCFXANGJQ+Z3L9Z245ncjyg69ZPOKV2njKH1y16h9eEe5SRG0FCbOG9 OoxKMstUb5k/8Mc1I8ke+fkWUS3ZBD7fQihiSeG5ObN7TvvV7g64uvzPgBByAUwH1Tg1 u8mg== MIME-Version: 1.0 X-Received: by 10.58.118.130 with SMTP id km2mr25775938veb.0.1379322536526; Mon, 16 Sep 2013 02:08:56 -0700 (PDT) Received: by 10.220.182.68 with HTTP; Mon, 16 Sep 2013 02:08:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 17:08:56 +0800 Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Chenchong Qin To: Adrian Chadd Content-Type: multipart/mixed; boundary=089e013a05acd23a0e04e67c8dbe 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:08:58 -0000 --089e013a05acd23a0e04e67c8dbe Content-Type: text/plain; charset=ISO-8859-1 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --089e013a05acd23a0e04e67c8dbe--