From owner-freebsd-wireless@FreeBSD.ORG Fri Sep 13 19:37:31 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 AAAE367C for ; Fri, 13 Sep 2013 19:37:31 +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 359B82CF2 for ; Fri, 13 Sep 2013 19:37:31 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id f12so1593428wgh.14 for ; Fri, 13 Sep 2013 12:37:29 -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=48npdcMhFKKp6HIufvjy2BSDeXHTTAhc2IMR7Rdn2vw=; b=TmjoPQpaX3dkUYHjNyL5c4/3d+RrEW+Dr58LGHIhkRhuV2k2OKIfEBJNnaYFS8Knj5 1uM516pbPIplwuPwoNG3AN2g1gxyME3Gd9wPZpYrHICKxdiwH8x4p2SxjfW3vCplj9ZU V2EG6hCvbuNSQdZaqie9XN3lyhDblrVMPyyCId4T5Aa7jM21yigo+1Nc1lcxVH9UPtYn fgO5aWEd2c5YplqcfJC/LwVIPz1Bu0sxIbJR5ShkTzqxw5WoD+K2uBvMnTqImz3Rtv4B UwopINOiOQM/QUryucPbv1qoC20LDJKZ9f6Pv8mTqPUub6aKaeaIO8rdwxHxJxHXXZPw JS8w== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr3934738wic.30.1379101049592; Fri, 13 Sep 2013 12:37:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Fri, 13 Sep 2013 12:37:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Sep 2013 12:37:29 -0700 X-Google-Sender-Auth: udLdDaSNhDI0vIAJv1mYhYaiUHk 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, 13 Sep 2013 19:37:31 -0000 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 >>>>>> >>>>>> >>>>> >>>> >>> >> >