Chenchong's work on net80211_ratectl
Chenchong Qin
qinchenchong at gmail.com
Wed Jul 24 08:39:16 UTC 2013
Hi!
Thanks for your constructive feedback!
First, I've done some renaming things. IEEE80211_RATECTL_OPT_* became
IEEE80211_RATECTL_CAP_* and options in ieee80211_ratectl
became ir_capabilities.
As for max4msframelen , I re-added this field and also ported
ath_max_4ms_framelen[4][32] to ieee80211_ratectl.
An error is also corrected (about initialization of ir_capabilities).
On Tue, Jul 23, 2013 at 10:30 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>
> * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ?
>
IEEE80211_RATECTL_OPT_MULTXCHAIN is used in ieee80211_ratectl_hascap_stbc()
to assist the determination of whether we can enable STBC.
* 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.
>
uh... I also do the "double check" stuff. Do the ieee80211_ratectl_hascap_*
functions do
wrong things? And, I'm not very clear about the relation between STBC and
short-GI now.
It seems that I need some further reading. :)
> * 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.
>
Yeah... here my logic messed up. It's corrected.
> * 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".
>
>
It's already done.
Thanks!
Chenchong
More information about the freebsd-wireless
mailing list