For now, yes, you have to assume that you won't always get a response for a
rate lookup. The buffer may be sent with NOACK set, it may be deleted
during a channel change or scan, etc.

And yes - the rate control lookup stuff for aggregate frames is a bit
messy. It would be nice for the rate control code to return the rate _and_
the maximum aggregate size, in case the aggregation selection wants to cap
how long frames are at the given choice.


On 11 September 2013 10:29, Chenchong Qin <qinchench...@gmail.com> wrote:

> Hi!
> I've added some aggregation support here!
> At first I intend to pass subframe informations(nframes, per-subframe
> length etc.)
> to the ratectl api. But it seems to be a paradox that rate lookup must be
> performed
> before the ampdu is formed (aggregation limit based on the rate control
> decision
> is need) and subframe informations can be obtain only after the ampdu is
> formed.
> So, I add a new ieee80211_rc_info flag to ieee80211_ratectl to let it
> distinguish
> aggregation and non-aggregation scenarios. If rate lookup is called in an
> aggregation
> scenario, this flag is set. Then, ratectl algo knows that it's now finding
> rates for an
> ampdu and the framelen which records len of the first frame can be
> ignored. When
> it comes to complete period, tx status that shows number of subframes been
> sent
> and number of subframes been successfully received is passed to the
> ratectl api.
> I also get a question here - whether one tx that doesn't perform rate
> lookup will call
> the complete procedure?
> Thanks!
> Chenchong
> On Sun, Sep 8, 2013 at 11:18 PM, Chenchong Qin <qinchench...@gmail.com>wrote:
>> Hi!
>> I've added the common ratectl state as an mbuf tag!
>> After days of frustration (compile errors, boot failed, kernel panics,
>> suddenly kernel freezing...), it seems that ath now can use 11n-aware
>> net80211 ratectl api to do rate control. Attachment[0] is the diff of
>> modifications to dev/ath. Changes to net80211 is minor this time. Just add
>> some debug msgs to it. Please reference my gsoc svn 
>> repo<https://svnweb.freebsd.org/socsvn/soc2013/ccqin/head/>
>> .
>> It's worth mentioning that sometimes the kernel will "freezing" (it looks
>> like all things stop working, screen is freezing, keyboard and mouse are
>> not responding) after wireless stuff start working for a while. At first, I
>> consider it caused by my modification to ath. But this strange thing can
>> also happen in a head kernel (r255382). Attachment[1] is some useful
>> messages just before it happens. By the way, I use a AR9227 device.
>> And, I found that, for aggregation scenario, ath gathers tx information
>> and update the ratectl states. So, what we can do to net80211 to let it
>> support aggregation?
>> Thanks!
>> Chenchong
>> On Tue, Sep 3, 2013 at 9:29 AM, Chenchong Qin <qinchench...@gmail.com>wrote:
>>> OK!
>>> Thanks! :-)
>>> Chenchong
>>> On Tue, Sep 3, 2013 at 1:56 AM, Adrian Chadd <adr...@freebsd.org> wrote:
>>>> Hi!
>>>> You can declare an mbuf tag and use that. Look at M_TXCB in net80211
>>>> and how mbuf tags are added.
>>>> I've long thought about adding a net80211 mbuf tag to represent -all-
>>>> of the tx related state - TX callback, rate control, rate completion,
>>>> aggregation state, retry count, etc. That way all the drivers can use it.
>>>> -adrian
freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to