Date: Tue, 23 Jul 2013 07:30:09 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Chenchong Qin <qinchenchong@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: Chenchong's work on net80211_ratectl Message-ID: <CAJ-Vmom4sY7jcNwWmJkrDwfWjsok2fk8UEwTi5A=egj1JyerLw@mail.gmail.com> In-Reply-To: <CAFnsE3dYdPf5yGTFH683Q1Zh0mc-g%2B_YtCTraNNt28z2vBoSKw@mail.gmail.com> References: <CAFnsE3dYdPf5yGTFH683Q1Zh0mc-g%2B_YtCTraNNt28z2vBoSKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! Feedback time! This is a good starting point! There's not a lot here yet, which is good. I didn't expect there to be! * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ? * The reason why I check both the vap/ic and the node bits for HT capabilities is that they're negotiated. The node bits are what the remote peer supports. The vap/ic bits are what the local device/vap supports. So, if the remote node supports STBC and the local node doesn't, we shouldn't try transmitting short-GI. * In ieee80211_ratectl_complete_rcflags(), enabling RTS/CTS but not transmitting an 11n rate isn't "right." The 11n hardware supports per-rate RTS/CTS for non-HT rates. You have to ensure that works. You've added a capability bit for this (IEEE80211_RATECTL_OPT_MRRPROT) so you should use it. * the new rate field "options" should be "ir_options", like how the rest of the fields are prefixed with ir_ * .. and, nitpicking, it should be "ir_capabilities". But this is a good starting point. Let's tidy this stuff up and then start work on on porting over ath_rate_sample into net80211. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom4sY7jcNwWmJkrDwfWjsok2fk8UEwTi5A=egj1JyerLw>