From owner-freebsd-wireless@FreeBSD.ORG Wed Sep 11 18:05:44 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 CBAE8809 for ; Wed, 11 Sep 2013 18:05:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 941352CFD for ; Wed, 11 Sep 2013 18:05:44 +0000 (UTC) Received: by mail-pb0-f53.google.com with SMTP id up15so9404801pbc.26 for ; Wed, 11 Sep 2013 11:05:44 -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=QuZZVX7+Pz+L2IEhJX9InSabuL4s3J9dsrv1mTj4Psw=; b=qRSn3KBNGmeT3bMs5M+f491/ibKOUw/JU/xKnoK7fDxyLdYM/RnjQ2lOzviisf0mq5 TpBOzjMc56AmRLz1+79fAAd5K0PNC0ywaPjlWByAPMPH+cmAwGBHHhw8lxzaNT6hhfVa dydKL4TJsLHjW3MI5KbraqhmHqFZwwfEbSfuADw+7tnUvfYNRGO7z4s40pWhxZO9yfKV I1nTgp5HMUQWHzAcSAWIZZIUOG9dZSQ26Zd4qisRtVXZXr6NCKIVQQsBVG03lnzjir9N XFcfkFygQwAx3C2tyrB4+CKIHZfxJLRVZgnlywK+4YeZQdkJytBDS2F2lB+Dtcn6Zt7h 1Qhg== MIME-Version: 1.0 X-Received: by 10.66.218.98 with SMTP id pf2mr5182268pac.120.1378922744269; Wed, 11 Sep 2013 11:05:44 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.126.71 with HTTP; Wed, 11 Sep 2013 11:05:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Sep 2013 11:05:44 -0700 X-Google-Sender-Auth: Jh--m4gPo-PaQaITi4km_1uSJSk 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: Wed, 11 Sep 2013 18:05:45 -0000 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 >>>> >>>> >>> >> >