netdev - Re: d80211-drivers pull request (week-48)

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <200612112328.14286.flamingice@sourmilk.net>
Date:	Mon, 11 Dec 2006 23:28:09 -0500
From:	Michael Wu <flamingice@...rmilk.net>
To:	Daniel Drake <dsd@...too.org>
Cc:	John Linville <linville@...driver.com>, netdev@...r.kernel.org,
	Ulrich Kunitz <kune@...ne-taler.de>
Subject: Re: d80211-drivers pull request (week-48)

On Monday 11 December 2006 22:51, Daniel Drake wrote:
> It's ugly, in my mind not necessary, and it will kill performance. We
> haven't had to make such compromises in a long time. We got a large TX
> speed boost when the driver was modified to queue up multiple transmit
> URBs (i.e. don't wait for URB completion of the first) at the same time
> early during driver development. And even with that we're still a fair
> distance from the performance of the vendor driver.
>
Yes, synchronous anything tends to kill performance. I do not see what about 
this patch kills performance, however. It merely frees skbs at a later point. 
The additional code in the RX path should be negligible. Also, every other 
d80211 driver has some sort of similar mechanism, the only difference being 
that  the one for zd1211rw-d80211 isn't as reliable. I do not think it is 
that ugly.

> While the stack isn't so well suited for this device I'd much prefer to
> see a more simplistic workaround. For example, assume all packets were
> successful but then report a failure when an interrupt comes in. Or, if
> the stack won't accept out-of-the-blue notifications like that, then
> maintain a counter which is incremented when a failure is reported, and
> when transmitting the next few frames report them as failed and
> decrement the counter (while counter > 0).
I don't think these solutions are much prettier than a tx_queue.

> Maybe disable rate control 
> until we can come up with a nicer solution.
>
I don't think that's gonna happen unless changes are made in the firmware, or 
there's some bit somewhere to flip that does exactly what we need. And 
surely, having some working rate control is better than requiring manual tx 
rate tuning, right? (which isn't an option in d80211 anyway)

-Michael Wu

Content of type "application/pgp-signature" skipped