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
pgpAau91AjvBt.pgp
Description: PGP signature
