Date: Wed, 31 Mar 2010 14:31:30 +0100 From: Rui Paulo <rpaulo@freebsd.org> To: Antoine Brodin <antoine@FreeBSD.org> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: net80211 ratectl proof of concept Message-ID: <63B143BF-20C9-425F-8969-B7452191E84F@freebsd.org> In-Reply-To: <p2xf19c444a1003310624r68579888jdddb0237d8da4b3f@mail.gmail.com> References: <D1EDB040-BB1F-41E2-8E1B-9DEF6171903D@gmail.com> <p2xf19c444a1003310624r68579888jdddb0237d8da4b3f@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Mar 2010, at 14:24, Antoine Brodin wrote: > On Wed, Mar 31, 2010 at 3:05 PM, Rui Paulo <rpaulo@gmail.com> wrote: >> Hi, >> I've started developing a ratectl framework for net80211, loosely = based on what DragonFly has. Right now only one driver has been ported, = but I would like your feedback before continuing. >>=20 >> The objective is to, eventually, have all the ratectl stuff (amrr, = sample, onoe(?) and rssadapt) in net80211 so all drivers can use it. We = can also select which ratectl modules are built in the kernel config = file. >> The framework support changing the current ratectl is out of scope = for this patch. >>=20 >> You can find the patch here: >> * http://people.freebsd.org/~rpaulo/ratectl.diff >>=20 >> Only the ral driver and the AMRR rate control algorithms were ported. >>=20 >> Some comments: >> o The rate control calls now dereferences several pointers and some = inline functions are now real functions. I wonder how much this impacts = performance and what we can do to solve it. >>=20 >> o I wished there was a better way to do the IEEE80211_AMRR_SUCCESS / = IEEE80211_AMRR_FAILURe call. >>=20 >> o Some other stuff can also be `const' >>=20 >> o I create ieee80211_ratect.[ch] to avoid polluting other files >>=20 >> o I moved the AMRR parameters inside amrr_init() on purpose. The = drivers we have now only specify a different interval and I plan to add = export amrr_set_interval() via the ratectl framework later. >>=20 >>=20 >> I would like very much to see this in, unless there's a strong = impending argument. >=20 > Hello, >=20 > This looks great! > Is there specific reasons to use pointers and not ints for some > arguments of foo_tx_complete() and foo_tx_update()? Not really. I'll probably switch them to ints at some point. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63B143BF-20C9-425F-8969-B7452191E84F>