From owner-freebsd-wireless@FreeBSD.ORG Sun Aug 25 14:39:52 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 5404CFFF for ; Sun, 25 Aug 2013 14:39:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AD1120D1 for ; Sun, 25 Aug 2013 14:39:51 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id n20so171590qaj.14 for ; Sun, 25 Aug 2013 07:39:51 -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=ukltFz9VpqImJfZwmcfKeoE8/qNtXUUx9PqBdnQESs8=; b=d2xtQMJ6CITda3b1lhYgIsUE6d867HtlIezJ1Mqb03c755Vr+NPStnzhCB+ptVLJbG x+skOmCUsHb6bJGNC7SRpyn4fqNffjANwtiGRrVrhbnvFmBYsoGjyhCil0du+j6OCj0y 3RoRNKCVnr5daJfeYYD39/XiTK2rxLV3L0bomnB5re/ExHNFsOMAhdqChvrkgSOr1a4F NDDfdKTItB8S1cuqg3HhJlCsCNo3tENC1ymd7w4fl1q1NFDbggzDlTTI59xZXGm5I4r8 rwJl3cEtAPiWHbXBJbKdLdkIIIvm1wn9I7cfh9uHd4Ya6DFx0qv+u4KISY85hdegVI7q ae0Q== MIME-Version: 1.0 X-Received: by 10.224.97.3 with SMTP id j3mr1146212qan.87.1377441591161; Sun, 25 Aug 2013 07:39:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.128.70 with HTTP; Sun, 25 Aug 2013 07:39:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 25 Aug 2013 07:39:51 -0700 X-Google-Sender-Auth: a-vqI41eufMM9OFvaX6BjwBT06A 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: Sun, 25 Aug 2013 14:39:52 -0000 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 >> >> >