Re: [PATCH] orinoco: take the driver lock in the rx tasklet

[Dave <kilroyd@googlemail.com>]

Andrey Borzenkov wrote:
> On 8 January 2009 21:24:16 Dave wrote:
>> The move to the RX tasklet was not motivated by improved performance,
>> but the requirements of the crypto library (can't call from
>> interrupt) and the need to do MIC calculations on RX.

> What exactly prevents crypto library being called from interrupt (aka 
> can it sleep)?

I don't know precisely, but have a look at the Developer section of
Documentation/crypto/api-intro.txt, and note that during RX we call the
setkey method of the MIC implementation to pass it the TKIP key.

> Because now it runs under spinlock with interrupts 
> disabled; how exactly does it differ from being called from interrupt 
> context?

Running in interrupt context is not necessarily the same as running with
interrupts disabled. For example, different platforms will have
different arrangements for your stack.

>> Unless the crypto routines have changed, reverting that commit will
>> break WPA support.

> For all I can tell, code now is functionally identical to code before 
> moving rx processing to tasklet. Meaning, if it was wrong before it 
> became just as wrong now.

That was the intent of this patch. Prior to WPA, the entire orinoco RX
path ran under a spinlock (and as far as I am aware was correct). After
WPA, only half did. The code is now as correct (or wrong) as it was
before the WPA patch (modulo the WPA stuff).

It is clear that a lot of the RX tasklet does not need to run with the
spinlock. But I prefer to reinstate the known correct locking behaviour
and then minimise what runs under the spinlock, than to try and go from
a broken state directly to an 'optimal' state.

One thing I want to play with (if I ever get time) is the whole locking
strategy in orinoco. I'm not a fan of the single lock protecting
hardware calls, driver data and now the RX queue. I would like to see if
we can separate them and get a bit of performance. Note that David
Gibson considered this a number of years back (more from the perspective
of USB support I think), and came to the opinion that the whole driver
should be serialized.

However I think this would be easier if we could get rid of all the WEXT
handlers, and configure the driver through the thinner cfg80211
interface. That is part of what my upcoming re-org of the orinoco driver
is aiming for.

I think that's enough from me for now...


Regards,

Dave.