From owner-freebsd-wireless@FreeBSD.ORG Mon Jul 22 05:17:59 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72DBEFB3 for ; Mon, 22 Jul 2013 05:17:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0C5C6224D for ; Mon, 22 Jul 2013 05:17:58 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id n57so5631811wev.28 for ; Sun, 21 Jul 2013 22:17:57 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZbKkNPEL0nbcr4+F7F8QEmXMkDDlJVBk3gDC8irK0WY=; b=A67lcXrvG2gzWn9paypVMSSPf/p1xMXtSJXz7vbkJa9RP7IBFDmJVGRwyWhzztv1RR ud2P2wnsnWvSXszIWjUl2h/RkzGL03fDlllK/G+z7fagSUMx3OgTxHB0nUW8WhfDMe2x wBEMc+e9fW7nMFXiZOQb7ey4KTp64ZpuzdheAXLVoAAMhuuItDTKgP8d/vLNYDkgQyeD yMZT+7Y8A3EVh+CbtFQW0KcJWejei5SVQG3NBH+WYjuwS37V/KajURtkVehEZq54hao0 zylVq5qp0NQXi3up6hPMxXG+Vk5cS61VY9lfoHh0WpT0Unpx8wGVi0EFGc//lBAkclJl zVsQ== MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr17872546wjs.79.1374470277217; Sun, 21 Jul 2013 22:17:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 21 Jul 2013 22:17:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Jul 2013 22:17:57 -0700 X-Google-Sender-Auth: _q4Plu0IF8bb2XBqS_I1CSBTDI4 Message-ID: Subject: Re: Chenchong's work on net80211_ratectl From: Adrian Chadd To: Chenchong Qin Content-Type: text/plain; charset=ISO-8859-1 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, 22 Jul 2013 05:17:59 -0000 hi! cool! I'll look at this soon. So, the max 4ms frame length is used when generating the aggregate frame. It's the maximum length that we can transmit. Look in the aggregate form stuff in if_ath_tx_ht.c We need it early on in order to know the maximum length that we can form A-MSDU frames, fast-frames, mesh/TDMA caps, etc. But great work! Let's keep it up! Adrian On 21 July 2013 20:28, Chenchong Qin wrote: > Hi, there! > > Attachment is the diff that contains my work on net80211_ratectl done these > days. > > I've done the fllowing things: > > 1) Add some rc options. > Chip can tell some options (i.e. whether mrr and mrrprot is support, whether > have more than 1 txchain, etc.) to rc code when rc is initializing. Then rc > algo can calc rates with these options in mind and do the right things. > > 2) Support multi-rate attempt. > Instead of returning just one rate, let rc return up to 4 rates. I add > ieee80211_rc_series. Basically, it's just a copy of ath_rc_series but drop > max4msframelen filed (it seems that max4msframelen is not used to setup the > rc stuffs). And at each rate lookup, rc can get shortPreamble and frameLen > info from the caller. > > 3) Support some 11n features. > Add some 11n features (i.e. cw40, short-gi, stbc) to net80211 rc stuffs. To > be frankly, I just let the rc algo decide whether to use the 11n features. > But I do provide rc algo with some abilities to know whether particular > feature can be used. Then, rc algo can do rate decisions based on these cap > info. > > Besides, I use iv_htcaps other than ic_htcaps to decide the 11n features > capabilities. I think iv_htcaps is more relevant to per vap rc operations > and I found iv_htcaps is just a copy of ic_htcaps at first (but some caps > may to be disabled by some vaps). But I'm not sure whether this can operate > properly by now. > > Once the rc algo decides to use one 11n feature for some rate attemps, it > must set corresponding rate flags. This is not the same as before. For now, > the rc algo get more power and then it comes more responsibility. > > 4) Complete the rc flags > After the rate lookup, we have an opportunity to make sure that rc code > doesn't mess it up. I blank tries 1, 2, 3 if rts/cts is enabled and it's a > pre-802.11n scenario. > > It's also the chance to fill some rate options/flags that the rc algo may > not be interested by now. > > Looking forward to your feedbacks! > > Thanks! > > Chenchong