Have you tried this out with any hardware just yet?
On 25 August 2013 07:30, Chenchong Qin <qinchench...@gmail.com> wrote:
> 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.
> On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin <qinchench...@gmail.com>wrote:
>> 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 <adr...@freebsd.org>wrote:
>>> 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
>> 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?
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"