From owner-freebsd-wireless@FreeBSD.ORG Sat Sep 14 15:21:08 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 34C27BAD for ; Sat, 14 Sep 2013 15:21:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B171D2BD9 for ; Sat, 14 Sep 2013 15:21:07 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id ex4so1924909wid.2 for ; Sat, 14 Sep 2013 08:21:05 -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=IxwK+efR59Htrbx9Iv53P6ODxg2ZnWHYZZ5cNmyldP8=; b=OPnb5McARP8FJm2aBG4khF6cylorHekExHMIc0VLLuAH8B/aAD4yQiXzjVmH8bUmis EQhj0WLguPP53qets1rP82K/4yfervghFCPPajuIkAChebXeJf/+UyfAA1+suz406FZZ M6xNuVdyBhG8a0Kyg1vFF0FI8qPXXUFQ8vWyrztTjNCrQLEsA19L4lZ+hGEnTxq6rIl1 RpbtDYWYO5dyykNFD1eBtNa5ZVTA3NPJC2TpsB8qVZO8vAQVe8INOn9ti2xC6l34ejYT 9vDKTNwmMVLi7d1QE5Hy3Gws3aJ+4kN2e6uFAJVFWqDmWEQe5bkmb3ndMmyV5x431Fz1 yq5w== MIME-Version: 1.0 X-Received: by 10.194.158.67 with SMTP id ws3mr15291088wjb.5.1379172065866; Sat, 14 Sep 2013 08:21:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Sat, 14 Sep 2013 08:21:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Sep 2013 08:21:05 -0700 X-Google-Sender-Auth: 3oONS0qhDBVhfxygjkwwkqSzj24 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: Sat, 14 Sep 2013 15:21:08 -0000 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 >>>> > 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 >>>>> > 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >