Chenchong's work on net80211_ratectl

[Chenchong Qin]

Hi!

Sorry to miss it. It's added now.

Thanks!

Chenchong


On Thu, Aug 15, 2013 at 12:34 AM, Adrian Chadd <adrian at freebsd.org> wrote:

> 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 <qinchenchong at 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 <adrian at 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 <qinchenchong at 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 <adrian at 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 <qinchenchong at 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 <adrian at freebsd.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> Boo!
>>> >> >>
>>> >> >> Do you have another update?
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> -adrian
>>> >> >>
>>> >> >> On 24 July 2013 06:44, Adrian Chadd <adrian at freebsd.org> wrote:
>>> >> >> > On 24 July 2013 06:38, Chenchong Qin <qinchenchong at 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
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>