From owner-freebsd-wireless@FreeBSD.ORG Tue Aug 27 09:02:11 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 7E0B6F63 for ; Tue, 27 Aug 2013 09:02:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33D5E283B for ; Tue, 27 Aug 2013 09:02:11 +0000 (UTC) Received: by mail-qe0-f53.google.com with SMTP id 1so2420187qee.12 for ; Tue, 27 Aug 2013 02:02:10 -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=ll0svDIhx6Vp80TJpY8Q+IlUIqLDFEKWt9cMgvKd9cg=; b=Ls5I0iw5StZgenoTT37/TOIvI/XDa24jUFgZ1UKlQpfpS3N3nlrXkA6q6B0P3c4Hko EKGgCpIUSZzHXFi3Urd8KQtCKbF0FDYfzD7a00ZIlCrhcFUY4ITD1gxd2+xtDiJsosfm V/cD3b6q7KXYuWiaMuc9GA9h1IKj0Eu6qfXqKhK1lYy3OFPKmqxai88eWdi4jTtFgsWh 0dEHeAuo/Nav/RuoMkCipu+frve/5XTg5ignHtK0k8eSr7eFkzfvKNggm50WvXcXgfyB Ol9yudriO+9eDeYxZ23FTCzqp7OOmUWMe3qhjEWN2yIHi/CZTNic4r+GfBmZvgvmfK6w ekqQ== MIME-Version: 1.0 X-Received: by 10.224.7.67 with SMTP id c3mr21257966qac.6.1377594130235; Tue, 27 Aug 2013 02:02:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Tue, 27 Aug 2013 02:02:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Aug 2013 02:02:10 -0700 X-Google-Sender-Auth: J0cogVk3vHplxPrP0mrY8pBA4Mk 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: Tue, 27 Aug 2013 09:02:11 -0000 Sweet! Let me know how it goes. -adrian On 25 August 2013 23:43, Chenchong Qin wrote: > Hi! > > I struggled to perform changes to all parts that affected by my update to > ratectl api > and got the customized kernel compiled... I'm now tring to play it on my > AR9227 device. > > Thanks! > > Chenchong > > > On Sun, Aug 25, 2013 at 10:39 PM, Adrian Chadd wrote: > >> Hi! >> >> Have you tried this out with any hardware just yet? >> >> >> -adrian >> >> >> >> On 25 August 2013 07:30, Chenchong Qin wrote: >> >>> Hi! >>> >>> This is the latest update. >>> >>> * add a simple per vap ratectl statistic tracker and api to update it. >>> * port irn_capabilities to irs_capabilities in struct ieee80211_rc_stat. >>> perhaps the capabilities field needs to be within ieee80211_rc_stat as >>> a per vap atrribute. corresponding updates performed. >>> * add ieee80211_ratectl_none.h to record common ratectl state. >>> >>> Thanks! >>> >>> Chenchong >>> >>> >>> On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin wrote: >>> >>>> Hi! >>>> >>>> Here is my latest update. In this update: >>>> >>>> * add a new struct, ieee80211_ratectl_node. This is the common state >>>> that all per node rc >>>> state, i.e. ieee80211_[amrr|sample]_node, should contains it as the >>>> first field. It's now used to store >>>> the capabilities. see below. >>>> * rename ir_capabilities to irn_capabilities and move it to >>>> ieee80211_ratectl_node (it contained in >>>> ieee80211_[amrr|sample]_node). ieee80211_ratectl is readonly, so >>>> ir_capabilities can't be set. And, >>>> the capabilities is not a part of rc algo. It seems that it should be >>>> put in the per node rc state. Interface >>>> of ieee80211_ratectl_node_init() and its callers are updated. >>>> References to ir_capabilities are also adapted. >>>> * add ieee80211_ratectl_[node_is11n|get_rateset] to the ratectl api. rc >>>> algoes all need these functions. >>>> * change the naming conversion of IEEE80211_RATECTL_FLAG_*. >>>> * some errors fixed. >>>> >>>> >>>> On Thu, Aug 15, 2013 at 12:58 AM, Adrian Chadd wrote: >>>> >>>>> 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. >>>>> >>>> >>>> Do you mean drop arg1/arg2 and pass pointer of ieee80211_rc_info to the >>>> complete function directly? Or return it >>>> when complete function return? >>>> >>>> >>>>> 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.) >>>>> >>>> >>>> Yeah, I have an AR9227 device at hand. >>>> >>>> And, I also get a question here. The ieee80211_ratetable doesn't get a >>>> rateCode field. So, how we get the >>>> ratecode of the non_ht rate? >>>> >>>> Thanks! >>>> >>>> Chenchong >>>> >>>> >>> >> >