Hi! Here is some updates.
Another member is added to ieee80211_rc_info to record value of the maximum aggregate size. Then, in aggregation scenario, ratectl algo can inform aggregation selection code of proper maximum aggregate size. Per-vap ratectl statistics is exported through sysctl. When ieee80211_ratectl_init() is called, this statistics api is attached. It's convenient to implement the per-device api -- just traverse the vap list and call per-vap api for each vap. But, we know that ratectl of net80211 provides service to vap-granularity object, not to device directly. So, is it more suitable to implement the per-device api in device driver (i.e. attach per-device api when attaching the device)? Code will be posted later. Thanks! Chenchong On Thu, Sep 12, 2013 at 2:05 AM, Adrian Chadd <[email protected]> wrote: > Hi, > > 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. > > > > -adrian > > > > On 11 September 2013 10:29, Chenchong Qin <[email protected]> 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 <[email protected]>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 <[email protected]>wrote: >>> >>>> OK! >>>> >>>> Thanks! :-) >>>> >>>> Chenchong >>>> >>>> >>>> On Tue, Sep 3, 2013 at 1:56 AM, Adrian Chadd <[email protected]>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 >>>>> >>>>> >>>> >>> >> > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "[email protected]"
