netdev - Re: RFC: always enable MAC80211_RC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1ba2fa240806261537h2dddf468h67243f84772d9da3@mail.gmail.com>
Date:	Fri, 27 Jun 2008 01:37:10 +0300
From:	"Tomas Winkler" <tomasw@...il.com>
To:	"Luis R. Rodriguez" <mcgrof@...il.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	"Adrian Bunk" <bunk@...nel.org>,
	"Johannes Berg" <johannes@...solutions.net>,
	"Adrian Bunk" <bunk@...sta.de>, linux-wireless@...r.kernel.org,
	netdev@...r.kernel.org,
	"Rindjunsky, Ron" <ron.rindjunsky@...el.com>
Subject: Re: RFC: always enable MAC80211_RC_PID?

On Fri, Jun 27, 2008 at 12:35 AM, Luis R. Rodriguez <mcgrof@...il.com> wrote:
> On Tue, Jun 24, 2008 at 2:12 PM, John W. Linville
> <linville@...driver.com> wrote:
>> On Tue, Jun 24, 2008 at 03:43:14PM +0300, Adrian Bunk wrote:
>>
>>> Can we get one of either:
>>> - all selected mac80211 algorithms are built into the mac80211 module or
>>
>> This seems fine to me.
>
> OK so just to be clear -- moving forward we strive to not allow driver
> specific rate control algorithms and push out current ones into
> mac80211? This would mean we don't have to *cleanup* support for
> driver specific RCs but instead just have them stashed in as part of
> the build. The difficulty here lies in ensuring they do work for well
> for other drivers but I do agree it strives to cleanup RC code. I
> think vendors also tend to use a few driver specific tweaks to boost
> their own throughput in their own RCs though. Can't say for sure right
> now of specific details but I'll try to get back to you with them.
> Perhaps Tomas can say more about that for iwl's RCs.
>
Annual talk about rate scaling algorithm :)
I understand of need of clean framework however:
Our rate scaling algorithm has intimate knowledge of iwlwifi firmware
and hardware and I'm currently not seeing any benefit for it for other
HW.
I'm also pretty much sure that no other algorithm can do same job for
iwlwifi driver.
For example the rate is not attached to each frame but supplied out of
band in a form of 16 steps rate sale table. I've explained already
benefits of this.

Detaching algorithm form the driver would at minimum require opening
another API for rate scaling not usable by others. And this is not the
end. This just doesn't worth the sweat if no other algorithm can be
used for iwlwifi and this algorithm cannot be used by others.
This would be cleaning code for sake of cleaning code without any
benefits. If there be finally some other 11n card in Linux we can see
the new picture and reevaluate.
I'm not the Kconfig expert but  desalinizing the current iwlwifi
driver for prize of removing MAC80211_RC_DEFAULT_NONE just doesn't
feel OK.
Thanks
Tomas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html