From owner-freebsd-wireless@FreeBSD.ORG Mon Sep 16 08:40:53 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 8CDC060D for ; Mon, 16 Sep 2013 08:40:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0E21C27D4 for ; Mon, 16 Sep 2013 08:40:52 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so3249587wgh.2 for ; Mon, 16 Sep 2013 01:40:51 -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=ne6jsUyB3BV/Q+7yO7DwGtA2nig8qsEE/HwWeWdz6JM=; b=JjFKgUGBEiK2lk18ls0hrKNKMfWQEcO6xSokOOzdYeTNVmpeVCS/UZLZ/tJAsUBNJr HFCh00/7CezL0Kf6NLG3xeZsSzgkd6rI17L1AgCvFbQs92reXpvIKWFFc5ljwW6MCju/ 7YzXTX5ytA1xt0YSDwaCTBUjprK3pqbW9duT8KBnNeb6ELqZoupQsMMLPbPQymi+6//z LHcBefDNJiCN5z6E00Cz/tXMZiQNQqSoRyhKJxzPKhQc7UGfdncRCwCjw1T90gYwQs+5 saax/a8xBJkatObfOaHZa8LLUia1FRcUw1ssFOBb1nSEoqvvhk6f6DsED9KzD2OTO/oe Zxqg== MIME-Version: 1.0 X-Received: by 10.180.10.136 with SMTP id i8mr12400383wib.46.1379320851402; Mon, 16 Sep 2013 01:40:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Mon, 16 Sep 2013 01:40:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Sep 2013 01:40:51 -0700 X-Google-Sender-Auth: EbJ8-B2ECLESiW2qY5dxgKLKQIQ 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: Mon, 16 Sep 2013 08:40:53 -0000 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >