Date: Wed, 17 Jul 2013 00:00:38 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Chenchong Qin <qinchenchong@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: great interest in the net80211 rate control API extension project in the wireless section of FreeBSD's GSoC 2013 idea list Message-ID: <CAJ-VmomLWE8yKRn0LuUyhPYdscmEkv%2BF%2BBECTtib-KTBk-vh6w@mail.gmail.com> In-Reply-To: <CAFnsE3dsmQAmuZV4nMvo44TQ0onofziUnSXgSYaQ1a8yoLMshg@mail.gmail.com> References: <CAFnsE3cvPr1ws18JQy8baO0z34%2BdaH%2BjkKYWDKB1pMU9tNpg%2BQ@mail.gmail.com> <CAJ-VmonLKBhha8DoY6sLBLXAF_UgU=Ny6zFq4knnit9Ccq7WBQ@mail.gmail.com> <CAFnsE3c5p2dbBevE73Z6CH5n8oh_ufnE6KxhrbF9sAO_WVURMA@mail.gmail.com> <CAJ-Vmonn=3y9ib%2BroyxuRzK-DUBcfG3buwj8VbgV2DcJJ0s%2B3Q@mail.gmail.com> <CAFnsE3epy9mEoRP4mcW-9_qq4tfuXhuhYEn3P9uY8MnT9jubCQ@mail.gmail.com> <CAJ-Vmo=AjSRr80gytYrGLvcyLjQY7zTjVDbNSzY5bkeLEmFgHQ@mail.gmail.com> <CAFnsE3cnhrdXt3AJD%2B1wfnWNhQBzgKx7nP1fyk-hs-9wornL0Q@mail.gmail.com> <CAJ-Vmo=4=HX1if9Fqd9g2F09qO%2BJqPQUokTX%2BpRJPLSz%2BDG%2Bmg@mail.gmail.com> <CAFnsE3dfDUETRhm%2BF=Sk%2BZ_wULGPVmWkJcuDfwv9kwM9bgq9ww@mail.gmail.com> <CAJ-VmonvR-V6earE3HE4n7BRdj49DvB7O22aoLas7FBsmwzG7A@mail.gmail.com> <CAFnsE3e2DnoE%2BdF81ugKkQQgBwAAy7%2BKfW9NfMwsMJugJWWXog@mail.gmail.com> <CAJ-Vmo=FjxC6jqHsV_EdC6LTU2zYcesFU_5UsXFVCJtPp0HaWw@mail.gmail.com> <CAFnsE3dsxH9Qryd%2B5=kkkUjKJtREgq4%2BDUgmHWYkXoqW%2BjiTeA@mail.gmail.com> <CAFnsE3cPuOY1NRRRsK1kC_rQ%2BHrBaHxSjryb3uNEFMBkb_5EOg@mail.gmail.com> <CAJ-VmomeaQs4phndcFDtM2ZmPY74tcjGX05A8po6x95ZKKG%2Bhg@mail.gmail.com> <CAJ-VmoksAMVU8_thzCufXaJa5fytvB9tXyWmaY5o2fiQqK2XCA@mail.gmail.com> <608F1F43-59F3-456D-A725-B36C2F9C2E75@gmail.com> <CAFnsE3eAu0Q_gfB-WFKZpDRxH8VHMvi=k69y711ZLAouy0%2BveA@mail.gmail.com> <CAJ-Vmon0-69jV_xfTAH7mDftFLMz8SyR53gZB-RMNdm9arKy2Q@mail.gmail.com> <CAJ-VmomQzW9x90qYuBq8fig99LBxwwjPJWqgv=z57Gi8yfvYLg@mail.gmail.com> <CAFnsE3d7yOSnfxz2NMiX14pZgVQLfLVnrCep%2Bb=DiVafCGZCeg@mail.gmail.com> <CAFnsE3eAxRE2L9dvzFOW7XJKccHA%2B2XCP8SYq=1yg2Cik5hkMg@mail.gmail.com> <CAJ-VmoneEPPYH5_pfNVUnrL5=YH=RYpCyHdeV4vVAtxHxOVH_A@mail.gmail.com> <CAJ-Vmom9CBeNso0Fu0M4TM8_u7oWmC=PkKw_Ucg0VhQ0weEyLA@mail.gmail.com> <CAFnsE3cYCydGTCMikp3YxEznbD5T2xeigq8qYBb%2BTD2bsTvynw@mail.gmail.com> <CAJ-Vmo=NKJYVUGuBHtEqZk-fRFsTDa-uZRruNLoQBepj6eq3WA@mail.gmail.com> <CAJ-Vmo=0eTQeUE8UkM_iNrhs%2BhTvi%2Brg8ybn1x4Zgm_QruYETQ@mail.gmail.com> <CAFnsE3fuR05w2vaA=LwG9vVFDT8Uu8TRHL53mA-KSuDsoVAyJw@mail.gmail.com> <CAFnsE3dsmQAmuZV4nMvo44TQ0onofziUnSXgSYaQ1a8yoLMshg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, >From now on, would you mind cc'ing freebsd-wireless@freebsd.org on discussions about this? I'd prefer to have this discussion in public so everyone can benefit! On 16 July 2013 20:28, Chenchong Qin <qinchenchong@gmail.com> wrote: > Hi! > > I've read your change to ieee80211_[phy amrr] and commited some code to my > soc repo. Cool! > For pre-802.11n, if rts/cts flag is set on retry 0, retries 1, 2, 3 can't be > used. And if rts/cts flag is not set on retry 0, we take it as a > non-protected rate series, rts/cts of retries 1, 2, 3 is useless neither. Right. This is specific to the Atheros hardware that supports this kind of multi-rate retry. > So, for non-11n scenario, I clear rts/cts flag of retries 1, 2, 3 and if > retry 0 enable rts/cts, blank tries 1, 2, 3. Is this logic resonable? Right. Well, what I think it should be is some kind of hardware capability that the chip tells the rate control code when it initialises. Ie; * I support multi-rate retry; * I support RTS for all rate retries (defaulting to the non-11n behaviour of _EITHER_ multi-rate retry + no RTSCTS, _OR_ single rate try + RTS/CTS > As for the 11n stuff for rate control, it seems to happen after lookup of > rates. Functions in if_ath_tx_ht.c, ie. ath_tx_rate_fill_rcflags and > ath_buf_set_rate, are called after ath_tx_do_ratelookup. Are we going to > implement all the same thing in one ieee80211_ratectrl_ functioin, or > sepreate functions? Well, what do you think? You're the one tinkering with this. :) Note that I've done it in a few places; * I do the rate lookup from ath_rate; * I then copy that into an ath_rc_series array; * I then "fix" the rate series up with 11n options - based purely on the negotiated parameters; * I convert the ath_rc_series into the HAL series, turning these options into hardware specific flags. Now, this means: * if it's a HT40 AP and STA, I always transmit HT40 - even though I could in theory choose to transmit HT20; * if the AP/STA support STBC, I always transmit STBC for MCS 0-7, but I in theory could choose not to; * If the AP/STA support short-GI, I always transmit it, even if I may choose not to; * etc. I did that because it's simple. But it may be that we should leave that up to the rate control module. It may decide to try transmitting HT20 only frames even though both sides are HT40. What do you think? -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomLWE8yKRn0LuUyhPYdscmEkv%2BF%2BBECTtib-KTBk-vh6w>