From owner-freebsd-wireless@FreeBSD.ORG Mon Aug 26 06:43:03 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 A268727B; Mon, 26 Aug 2013 06:43:03 +0000 (UTC) (envelope-from qinchenchong@gmail.com) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 460682C1E; Mon, 26 Aug 2013 06:43:03 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 15so1942927vea.1 for ; Sun, 25 Aug 2013 23:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IAjIK4+yZrPu2ioqZYNYBpMyVtBKXVr0PDYnPCzV3qU=; b=Q4V6N5hV81i8w7SHPJmpRF4r1LPp8EOImF1VYJE6RueCOSH12D1M0bn2vnxNReS+Gx MhlwvlwsafZA38kGC09Sy0iU2cJdV0iUinLewcktX2Wi3NEVmto9gaiFRRtK23sWW6hF KcnKMM6n3ZyBAg0MFWFsWFIGEYuV67ae/0E7FgwG2JCjHf4qfvdRCW7NrgBRBlhUeeOH ZpaXq3PnA1+mKtm+T7nGh91qTD6P74A7IpAWgxzkjimp1K15v07C1X3nTLx5RrZ1L5rO TKY4uYvwRrNYF6jNGilpWyTl8PWRu0Z3WAQJONtvyR8QKDl+uZ7RXUoMF6953ZJEoqlm SE/A== MIME-Version: 1.0 X-Received: by 10.58.201.227 with SMTP id kd3mr13851059vec.14.1377499382356; Sun, 25 Aug 2013 23:43:02 -0700 (PDT) Received: by 10.220.182.68 with HTTP; Sun, 25 Aug 2013 23:43:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Aug 2013 14:43:02 +0800 Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Chenchong Qin To: Adrian Chadd 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: Mon, 26 Aug 2013 06:43:03 -0000 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 >>> >>> >> >