Cool! I'll check it out once I have finished traveling.

Thanks for all your hard work!

Adrian
On Sep 19, 2013 8:06 PM, "Chenchong Qin" <qinchench...@gmail.com> wrote:

> Hi!
>
> Here is the final version and some output from ifconfig and sysctl.
>
> Thanks!
>
> Chenchong
>
>
> On Thu, Sep 19, 2013 at 11:09 AM, Chenchong Qin <qinchench...@gmail.com>wrote:
>
>> OK!
>>
>> I'll post it later. :)
>>
>> Thanks!
>>
>> Chenchong
>>
>>
>> On Thu, Sep 19, 2013 at 9:38 AM, Adrian Chadd <adr...@freebsd.org> wrote:
>>
>>> Sweet, thanks!
>>>
>>> Please post the final and some sample output from ifconfig and sysctl
>>> somewhere so we can take a more detailed look.
>>>
>>> I'll be travelling over the next few days; I'll try to get it all
>>> finalised later this month.
>>>
>>> Thanks again! Great work!
>>>
>>>
>>> -adiran
>>>
>>>
>>>
>>> On 16 September 2013 02:32, Chenchong Qin <qinchench...@gmail.com>wrote:
>>>
>>>> Hi!
>>>>
>>>> In this update, I update ieee80211_sample and complete
>>>> ieee80211_ratectl_none templete.
>>>>
>>>> * rename ieee80211_rc_sample* to ieee80211_sample*. this seems to be
>>>> more harmonious.
>>>> * modify ieee80211_sample to let it use the latest net80211-ratectl
>>>> features.
>>>> * fix some errors in ieee80211_sample.
>>>> * complete the ieee80211_ratectl_none templete with newly added
>>>> net80211-ratectl functions.
>>>>
>>>> You will need to add wlan_sample to sys/conf/files to make
>>>> ieee80211_sample compiled.
>>>>
>>>> Thanks!
>>>>
>>>> Chenchong
>>>>
>>>>
>>>> On Mon, Sep 16, 2013 at 5:08 PM, Chenchong Qin 
>>>> <qinchench...@gmail.com>wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Yes!
>>>>>
>>>>> Here is a fresh debug log.
>>>>>
>>>>> @adrian you may received many copies of this message because I got the
>>>>> "Message body too large" limit of freebsd-wireless list. So I compress
>>>>> the
>>>>> log file and re-send it. Sorry to be confused. :)
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Chenchong
>>>>>
>>>>>
>>>>> On Mon, Sep 16, 2013 at 4:40 PM, Adrian Chadd <adr...@freebsd.org>wrote:
>>>>>
>>>>>> Sweet!
>>>>>>
>>>>>> Does this work on your AR9227? Can you provide some example output?
>>>>>>
>>>>>>
>>>>>> -a
>>>>>>
>>>>>>
>>>>>> On 14 September 2013 21:08, Chenchong Qin <qinchench...@gmail.com>wrote:
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> Yes, a call to ieee80211_ratectl_rc_info_set() is needed. To make
>>>>>>> other drivers work, the __init__ and __findrate__ parts also need to be
>>>>>>> adapted.
>>>>>>> When initialize the ratectl state, a cap flag must be properly set
>>>>>>> and feed to ieee80211_ratectl_init().  __findrate__ part should be 
>>>>>>> repalced
>>>>>>> with our
>>>>>>> ieee80211_ratectl_rates().
>>>>>>>
>>>>>>> I've added  ieee80211_ratectl_rc_info_get() to be used to get the
>>>>>>> ieee80211_rc_info. If found the tag, use it; if not, add a new one and 
>>>>>>> use
>>>>>>> it. Then we don't
>>>>>>> need to free it explicitly (the tag is freed when associated mbuf
>>>>>>> is freed) and this interface is unified to both __findrate__ and
>>>>>>> __complete__.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Chenchong
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Sep 14, 2013 at 11:21 PM, Adrian Chadd 
>>>>>>> <adr...@freebsd.org>wrote:
>>>>>>>
>>>>>>>> Ah, cool! I see you've only just made the other drivers compile;
>>>>>>>> what's required to make them work? i guess a call
>>>>>>>> to ieee80211_ratectl_rc_info_set() ?
>>>>>>>>
>>>>>>>> Maybe you should add a ieee80211_ratectl_rc_info_set_mbuf() helper
>>>>>>>> that does the "lookup tag; if one exists use it else use a temporary 
>>>>>>>> one"
>>>>>>>> code that you put in if_ath.c, if_ath_tx.c.
>>>>>>>>
>>>>>>>> Other than that, this is looking very good! thankyou!
>>>>>>>>
>>>>>>>>
>>>>>>>> -adrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13 September 2013 20:52, Chenchong Qin 
>>>>>>>> <qinchench...@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Here is latest update. Per-device ratectl statistics is
>>>>>>>>> implemented in ath and attached when ath is attaching.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Chenchong
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Sep 14, 2013 at 3:37 AM, Adrian Chadd 
>>>>>>>>> <adr...@freebsd.org>wrote:
>>>>>>>>>
>>>>>>>>>> Sweet, thanks!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -adrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 13 September 2013 09:11, Chenchong Qin <qinchench...@gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> 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 <
>>>>>>>>>>> adr...@freebsd.org> 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 <
>>>>>>>>>>>> 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
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to