Re: Chenchong's work on net80211_ratectl
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.comwrote: 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.comwrote: 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.comwrote: 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.orgwrote: Sweet! Does this work on your AR9227? Can you provide some example output? -a On 14 September 2013 21:08, Chenchong Qin qinchench...@gmail.comwrote: 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.orgwrote: 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.comwrote: 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.orgwrote: 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
Re: Chenchong's work on net80211_ratectl
Hi! Thanks for your reminder! I've posted it to my project pagehttps://wiki.freebsd.org/SummerOfCode2013/80211RateControl80211nExtensions. You can now download it from the Code section in the bottom. Thanks again! Chenchong On Sat, Sep 21, 2013 at 11:10 AM, Sean Bruno sean_br...@yahoo.com wrote: There was no .tar.gz file attached to the email. It was probably stripped by freebsd.org. You'll probably need to post it somewhere for us to download. Sean On Sat, 2013-09-21 at 08:08 +0800, Chenchong Qin wrote: Hi! It's in the .tar.gz file attached in last mail. Thanks! Chenchong On Sat, Sep 21, 2013 at 12:13 AM, Sean Bruno sean_br...@yahoo.com wrote: On Fri, 2013-09-20 at 11:06 +0800, Chenchong Qin wrote: Hi! Here is the final version and some output from ifconfig and sysctl. Thanks! Chenchong I didn't see anything attached to this message that looks like a patch. Where should I go to try out your changes? sean On Thu, Sep 19, 2013 at 11:09 AM, Chenchong Qin qinchench...@gmail.comwrote: 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.comwrote: 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.orgwrote: Sweet! Does this work on your AR9227? Can you provide some example output? -a On 14 September 2013 21:08, Chenchong Qin qinchench...@gmail.comwrote: 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.orgwrote: Ah, cool! I see you've only just made the other drivers
Re: Chenchong's work on net80211_ratectl
Sure; but I don't want to use people are breaking things as justification to further break things. :-) 10.0 can ship without this. I'd rather this settle in -HEAD and convert / test all the other drivers over first before we consider MFC'ing it to -10. adrian On 19 September 2013 01:35, Lev Serebryakov l...@freebsd.org wrote: Hello, Adrian. You wrote 19 сентября 2013 г., 12:32:45: AC hah, nope. This will go into -HEAD when it's ready. I'm not going to rush AC things. HEAD is already a bit ... special. What do you mean?! -HEAD and 10-ALPHA2 are two names for same thing now :) And it is frozen, yes, but svn up shows me major commits (like ine iSCSI or Hyper-V drivers) every day :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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
Re: Chenchong's work on net80211_ratectl
Hello, Adrian. You wrote 19 сентября 2013 г., 12:37:46: AC 10.0 can ship without this. I'd rather this settle in -HEAD and convert / AC test all the other drivers over first before we consider MFC'ing it to -10. MFC is Ok too :) -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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
Re: Chenchong's work on net80211_ratectl
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.comwrote: 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.comwrote: 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.orgwrote: Sweet! Does this work on your AR9227? Can you provide some example output? -a On 14 September 2013 21:08, Chenchong Qin qinchench...@gmail.comwrote: 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.orgwrote: 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.comwrote: 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.orgwrote: Sweet, thanks! -adrian On 13 September 2013 09:11, Chenchong Qin qinchench...@gmail.comwrote: 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
Re: Chenchong's work on net80211_ratectl
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.comwrote: 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.comwrote: 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.orgwrote: 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.comwrote: 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.orgwrote: Sweet, thanks! -adrian On 13 September 2013 09:11, Chenchong Qin qinchench...@gmail.comwrote: 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.orgwrote: 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.comwrote: 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,
Re: Chenchong's work on net80211_ratectl
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.orgwrote: 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.comwrote: 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 repohttps://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.orgwrote: 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 ___
Re: Chenchong's work on net80211_ratectl
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
Re: Chenchong's work on net80211_ratectl
Sweet! Let me know how it goes. -adrian On 25 August 2013 23:43, Chenchong Qin qinchench...@gmail.com wrote: Hi! I struggled to perform changes to all parts that affected by my update to ratectl api and got the customized kernel compiled... I'm now tring to play it on my AR9227 device. Thanks! Chenchong On Sun, Aug 25, 2013 at 10:39 PM, Adrian Chadd adr...@freebsd.org wrote: Hi! Have you tried this out with any hardware just yet? -adrian On 25 August 2013 07:30, Chenchong Qin qinchench...@gmail.com wrote: Hi! 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. Thanks! Chenchong On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin qinchench...@gmail.comwrote: Hi! 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.orgwrote: Hi! 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 drivers. 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? 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
Re: Chenchong's work on net80211_ratectl
Hi! I struggled to perform changes to all parts that affected by my update to ratectl api and got the customized kernel compiled... I'm now tring to play it on my AR9227 device. Thanks! Chenchong On Sun, Aug 25, 2013 at 10:39 PM, Adrian Chadd adr...@freebsd.org wrote: Hi! Have you tried this out with any hardware just yet? -adrian On 25 August 2013 07:30, Chenchong Qin qinchench...@gmail.com wrote: Hi! 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. Thanks! Chenchong On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin qinchench...@gmail.comwrote: Hi! 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.orgwrote: Hi! 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 drivers. 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? 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
Re: Chenchong's work on net80211_ratectl
Hi! Just a note - you need to keep the old copyright headers for code you've just shifted around. Eg, the ieee80211_rc_sample.[ch] files. -adrian On 13 August 2013 05:21, Chenchong Qin qinchench...@gmail.com wrote: Hi! Here is an update of work these days. I've added a new struct called ieee80211_rc_info to the ratectl API. It contains tx completing information, i.e. txcnt, retrycnt, finaltsi, etc, which can be provided to ratectl algo during the __complete__ period. ir_rates, ieee80211_ratectl_rates and ieee80211_ratectl_complete_rcflags are adapted to accept the ieee80211_rc_info pointer through which framelen and shortpreamble can also be reached. Then I added __complete__ stuff and ir_rates to ieee80211_rc_sample. Thanks! Chenchong On Tue, Aug 6, 2013 at 12:03 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! Great! So what's the problem with complete? Linux just provides all the information that the NIC supplies - how many attempts were made, how many attempts failed, which rate suceeded, etc. It looks a lot like it was designed around the requirements for the atheros driver (that has the most interesting information available) and other NICs just have to fake it somehow. -adrian On 5 August 2013 08:58, Chenchong Qin qinchench...@gmail.com wrote: Hi! Here is my work done these days on porting ath_rate_sample to net80211. It has not been finished yet. _complete_ and _update_ are to be added. _complete_ is really a tricky thing. We have to provide rc algos with rc information during the frame completion period. Different rc algos may need different rc information. What makes things more thornier is that different drivers provide different rc information in different ways. So, it seems we need a unified way to provide the rc information during completion of a frame. I'm browsing mac80211 these days to see what Linux do about _complete_. And, looking forward to your commets! Thanks! Chenchong On Sat, Aug 3, 2013 at 1:30 AM, Adrian Chadd adr...@freebsd.org wrote: Well just remember you can always ask me/us questions! What's your latest diff against -HEAD? Maybe I can start looking at including parts of it in the tree. -adrian On 2 August 2013 09:17, Chenchong Qin qinchench...@gmail.com wrote: Hi! These days, I'm taking a further look at what Linux done for the _completion_ of a frame. Some updates will be posted here later. And, with ir_rates, we can return/fill an rc array rather than just returning the rix. Thanks! Chenchong On Thu, Aug 1, 2013 at 12:21 AM, Adrian Chadd adr...@freebsd.org wrote: Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with 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
Re: Chenchong's work on net80211_ratectl
Hi! Great! So what's the problem with complete? Linux just provides all the information that the NIC supplies - how many attempts were made, how many attempts failed, which rate suceeded, etc. It looks a lot like it was designed around the requirements for the atheros driver (that has the most interesting information available) and other NICs just have to fake it somehow. -adrian On 5 August 2013 08:58, Chenchong Qin qinchench...@gmail.com wrote: Hi! Here is my work done these days on porting ath_rate_sample to net80211. It has not been finished yet. _complete_ and _update_ are to be added. _complete_ is really a tricky thing. We have to provide rc algos with rc information during the frame completion period. Different rc algos may need different rc information. What makes things more thornier is that different drivers provide different rc information in different ways. So, it seems we need a unified way to provide the rc information during completion of a frame. I'm browsing mac80211 these days to see what Linux do about _complete_. And, looking forward to your commets! Thanks! Chenchong On Sat, Aug 3, 2013 at 1:30 AM, Adrian Chadd adr...@freebsd.org wrote: Well just remember you can always ask me/us questions! What's your latest diff against -HEAD? Maybe I can start looking at including parts of it in the tree. -adrian On 2 August 2013 09:17, Chenchong Qin qinchench...@gmail.com wrote: Hi! These days, I'm taking a further look at what Linux done for the _completion_ of a frame. Some updates will be posted here later. And, with ir_rates, we can return/fill an rc array rather than just returning the rix. Thanks! Chenchong On Thu, Aug 1, 2013 at 12:21 AM, Adrian Chadd adr...@freebsd.org wrote: Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with 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
Re: Chenchong's work on net80211_ratectl
Hi! These days, I'm taking a further look at what Linux done for the _completion_ of a frame. Some updates will be posted here later. And, with ir_rates, we can return/fill an rc array rather than just returning the rix. Thanks! Chenchong On Thu, Aug 1, 2013 at 12:21 AM, Adrian Chadd adr...@freebsd.org wrote: Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with 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
Re: Chenchong's work on net80211_ratectl
Well just remember you can always ask me/us questions! What's your latest diff against -HEAD? Maybe I can start looking at including parts of it in the tree. -adrian On 2 August 2013 09:17, Chenchong Qin qinchench...@gmail.com wrote: Hi! These days, I'm taking a further look at what Linux done for the _completion_ of a frame. Some updates will be posted here later. And, with ir_rates, we can return/fill an rc array rather than just returning the rix. Thanks! Chenchong On Thu, Aug 1, 2013 at 12:21 AM, Adrian Chadd adr...@freebsd.org wrote: Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with 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
Re: Chenchong's work on net80211_ratectl
Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with 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
Re: Chenchong's work on net80211_ratectl
Hi! Thanks for your constructive feedback! First, I've done some renaming things. IEEE80211_RATECTL_OPT_* became IEEE80211_RATECTL_CAP_* and options in ieee80211_ratectl became ir_capabilities. As for max4msframelen , I re-added this field and also ported ath_max_4ms_framelen[4][32] to ieee80211_ratectl. An error is also corrected (about initialization of ir_capabilities). On Tue, Jul 23, 2013 at 10:30 PM, Adrian Chadd adr...@freebsd.org wrote: * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ? IEEE80211_RATECTL_OPT_MULTXCHAIN is used in ieee80211_ratectl_hascap_stbc() to assist the determination of whether we can enable STBC. * The reason why I check both the vap/ic and the node bits for HT capabilities is that they're negotiated. The node bits are what the remote peer supports. The vap/ic bits are what the local device/vap supports. So, if the remote node supports STBC and the local node doesn't, we shouldn't try transmitting short-GI. uh... I also do the double check stuff. Do the ieee80211_ratectl_hascap_* functions do wrong things? And, I'm not very clear about the relation between STBC and short-GI now. It seems that I need some further reading. :) * In ieee80211_ratectl_complete_rcflags(), enabling RTS/CTS but not transmitting an 11n rate isn't right. The 11n hardware supports per-rate RTS/CTS for non-HT rates. You have to ensure that works. You've added a capability bit for this (IEEE80211_RATECTL_OPT_MRRPROT) so you should use it. Yeah... here my logic messed up. It's corrected. * the new rate field options should be ir_options, like how the rest of the fields are prefixed with ir_ * .. and, nitpicking, it should be ir_capabilities. It's already done. 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
Re: Chenchong's work on net80211_ratectl
cool! Would you mind posting an updated diff? -adrian On 24 July 2013 01:39, Chenchong Qin qinchench...@gmail.com wrote: Hi! Thanks for your constructive feedback! First, I've done some renaming things. IEEE80211_RATECTL_OPT_* became IEEE80211_RATECTL_CAP_* and options in ieee80211_ratectl became ir_capabilities. As for max4msframelen , I re-added this field and also ported ath_max_4ms_framelen[4][32] to ieee80211_ratectl. An error is also corrected (about initialization of ir_capabilities). On Tue, Jul 23, 2013 at 10:30 PM, Adrian Chadd adr...@freebsd.org wrote: * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ? IEEE80211_RATECTL_OPT_MULTXCHAIN is used in ieee80211_ratectl_hascap_stbc() to assist the determination of whether we can enable STBC. * The reason why I check both the vap/ic and the node bits for HT capabilities is that they're negotiated. The node bits are what the remote peer supports. The vap/ic bits are what the local device/vap supports. So, if the remote node supports STBC and the local node doesn't, we shouldn't try transmitting short-GI. uh... I also do the double check stuff. Do the ieee80211_ratectl_hascap_* functions do wrong things? And, I'm not very clear about the relation between STBC and short-GI now. It seems that I need some further reading. :) * In ieee80211_ratectl_complete_rcflags(), enabling RTS/CTS but not transmitting an 11n rate isn't right. The 11n hardware supports per-rate RTS/CTS for non-HT rates. You have to ensure that works. You've added a capability bit for this (IEEE80211_RATECTL_OPT_MRRPROT) so you should use it. Yeah... here my logic messed up. It's corrected. * the new rate field options should be ir_options, like how the rest of the fields are prefixed with ir_ * .. and, nitpicking, it should be ir_capabilities. It's already done. 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
Re: Chenchong's work on net80211_ratectl
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
