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 <qinchench...@gmail.com> 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 _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
