From owner-freebsd-wireless@FreeBSD.ORG Wed Aug 14 16:58:24 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 32C4B604 for ; Wed, 14 Aug 2013 16:58:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A8B69277F for ; Wed, 14 Aug 2013 16:58:23 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id l18so7784251wgh.35 for ; Wed, 14 Aug 2013 09:58:22 -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=uewyV+sT6fsEGSPAbUWR4hfIAQjdFRSWiMWDDlLPUsg=; b=LG49ktrzn62iR6XTLw0FOlGyaBOELyI1cOYmWqxMfgdH4wbRH+a6v/iFudbLkvaUGX hbYZ6hY/ehc2oVqAKLeiuwmtFeYknsucqhjG5Nmvaw159z7B2zsgCKsgM+A7OYOmugeK DSsRMQuq5zjMPTuXj8BDagDIN/N9sbI8WfTpWZYfaJIIbasKl2cdt2E+Hd0glfebIoAc xl86R2QqkW89hbwd1dBGJMATsxvi01IfJqqCtuxv8Z+jaAvyIvo1wLBP38EM/IML4AEC tiiacIuRwcdKB8V44oa1cvec9tSLBTvErR2XispXbiyINIa2ZEy0318sHffq+cFsTaUA SPGw== MIME-Version: 1.0 X-Received: by 10.180.10.99 with SMTP id h3mr2326740wib.0.1376499501924; Wed, 14 Aug 2013 09:58:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.116.136 with HTTP; Wed, 14 Aug 2013 09:58:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Aug 2013 09:58:21 -0700 X-Google-Sender-Auth: eIJyHqV0jx190qAQdTudKMqzdyA 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, 14 Aug 2013 16:58:24 -0000 Hi! So yes, we do need to have a generic way of returning that completion information to the rate control code. I'm all for you churning the rate control API to return a struct ieee80211_rc_info in the complete function and totally just kill arg1/arg2. That forces us to extend ieee80211_rc_info to be "right" for all the drivers. What wifi devices do you have there? It looks like we're almost at the point where we can start converting a few things to use the modified rate control API and modules - notably iwn (which won't use the multi-rate retry stuff to begin with - it works "differently"..) and ath (which will use the multi-rate retry stuff and the sample rate control module.) Thanks! -adrian On 14 August 2013 09:34, Adrian Chadd wrote: > Hi! > > Just a note - you need to keep the old copyright headers for code you've > just shifted around. > > Eg, the ieee80211_rc_sample.[ch] files. > > > -adrian > > > > On 13 August 2013 05:21, Chenchong Qin wrote: > >> Hi! >> >> Here is an update of work these days. >> >> I've added a new struct called ieee80211_rc_info to the ratectl API. It >> contains tx completing information, i.e. txcnt, retrycnt, finaltsi, etc, >> which >> can be provided to ratectl algo during the __complete__ period. ir_rates, >> ieee80211_ratectl_rates and ieee80211_ratectl_complete_rcflags are >> adapted to accept the ieee80211_rc_info pointer through which framelen >> and shortpreamble can also be reached. Then I added __complete__ stuff >> and ir_rates to ieee80211_rc_sample. >> >> Thanks! >> >> Chenchong >> >> >> On Tue, Aug 6, 2013 at 12:03 AM, Adrian Chadd wrote: >> >>> Hi! >>> >>> Great! >>> >>> So what's the problem with complete? Linux just provides all the >>> information that the NIC supplies - how many attempts were made, how >>> many attempts failed, which rate suceeded, etc. It looks a lot like it >>> was designed around the requirements for the atheros driver (that has >>> the most interesting information available) and other NICs just have >>> to fake it somehow. >>> >>> >>> >>> -adrian >>> >>> On 5 August 2013 08:58, Chenchong Qin wrote: >>> > Hi! >>> > >>> > Here is my work done these days on porting ath_rate_sample to >>> net80211. It >>> > has not been finished yet. _complete_ and _update_ are to be added. >>> > >>> > _complete_ is really a tricky thing. We have to provide rc algos with >>> rc >>> > information >>> > during the frame completion period. Different rc algos may need >>> different rc >>> > information. What makes things more thornier is that different drivers >>> > provide >>> > different rc information in different ways. So, it seems we need a >>> unified >>> > way to >>> > provide the rc information during completion of a frame. >>> > >>> > I'm browsing mac80211 these days to see what Linux do about >>> _complete_. And, >>> > looking forward to your commets! >>> > >>> > Thanks! >>> > >>> > Chenchong >>> > >>> > >>> > On Sat, Aug 3, 2013 at 1:30 AM, Adrian Chadd >>> wrote: >>> >> >>> >> Well just remember you can always ask me/us questions! >>> >> >>> >> What's your latest diff against -HEAD? Maybe I can start looking at >>> >> including parts of it in the tree. >>> >> >>> >> >>> >> >>> >> >>> >> -adrian >>> >> >>> >> On 2 August 2013 09:17, Chenchong Qin wrote: >>> >> > Hi! >>> >> > >>> >> > These days, I'm taking a further look at what Linux done for the >>> >> > _completion_ of a >>> >> > frame. Some updates will be posted here later. >>> >> > >>> >> > And, with ir_rates, we can return/fill an rc array rather than just >>> >> > returning the rix. >>> >> > >>> >> > Thanks! >>> >> > >>> >> > Chenchong >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > On Thu, Aug 1, 2013 at 12:21 AM, Adrian Chadd >>> >> > wrote: >>> >> >> >>> >> >> Boo! >>> >> >> >>> >> >> Do you have another update? >>> >> >> >>> >> >> >>> >> >> >>> >> >> -adrian >>> >> >> >>> >> >> On 24 July 2013 06:44, Adrian Chadd wrote: >>> >> >> > On 24 July 2013 06:38, Chenchong Qin >>> wrote: >>> >> >> >> >>> >> >> >> My pleasure! >>> >> >> >> >>> >> >> >> It's also against HEAD. >>> >> >> >> >>> >> >> >> Thanks! >>> >> >> > >>> >> >> > Ok. This is looking great! >>> >> >> > >>> >> >> > Next - we need to update the rate control API to now populate an >>> rc >>> >> >> > array rather than just returning the rix. >>> >> >> > >>> >> >> > This is the tricky part - as we're going to have to modify all >>> the >>> >> >> > drivers that use the rate control API to use this. >>> >> >> > Which is fine, as there's only a handful. It's just annoying. >>> >> >> > >>> >> >> > Then we have to provide the rate control information during frame >>> >> >> > _completion_, so the rate control code knows which transmission >>> rates >>> >> >> > succeeded or failed. I'm still not sure what to do about it here. >>> >> >> > Maybe do something like Linux and attach TX rate control and >>> >> >> > completion information as an mbuf tag? >>> >> >> > >>> >> >> > _Then_ we can start doing interesting thing with it. :) >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -adrian >>> >> > >>> >> > >>> > >>> > >>> >> >> >