Chenchong's work on net80211_ratectl

[Chenchong Qin]

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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20130812-net80211-ratectl.diff
Type: application/octet-stream
Size: 67435 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-wireless/attachments/20130813/557eb1b9/attachment.obj>