On Tue, 2008-02-26 at 00:50 +0200, Tomas Winkler wrote:

On Mon, Feb 25, 2008 at 10:46 PM, Johannes Berg
[off-list ref] wrote:

quoted

 On Fri, 2008-02-22 at 10:57 -0500, John W. Linville wrote:
 > On Fri, Feb 22, 2008 at 04:16:49PM +0100, Johannes Berg wrote:
 > >
 > > > > Hence, I think we can actually get away without more locking if we
 > > > > protect the flags better. Should we use a spinlock or the atomic
 > > > > set_bit()/clear_bit()/etc. operations?
 > > >
 > > > Using the atomic operations seems appropriate to me.
 > >
 > > Right, but I figured if we could get rid of the AMPDU spinlocks and just
 > > use a single one in total (for flags as well) then that'd be of benefit
 > > too; even with the dynamic allocation strategy (see other mail) we'd not
 > > need to allocate two more spinlocks for ampdu.
 >
 > Yes, I thought that was behind your question.  I'll let Ron comment
 > on the AMPDU spinlock usage.

 Ok so the mesh code came with a spinlock too, the AMPDU code has two.

 Ron/Tomas, does the ampdu MLME really need two spinlocks?

The problem is that RX a TX BA establishments usually happens
concurrently for single STA, those are independent state machines.  We
have to review this carefully before spinlokcs are removed.

I wouldn't want to remove them, but it seems overkill two have two
spinlocks. What I'd like to do is remove the ampdu tx, ampdu rx and mesh
spinlocks and instead use just a single one for all three uses, and then
use that one to protect the flags as well.

It seems to me that even if the RX/TX BA establishment is happening
concurrently then it's still serialized by the frames on the air so
ultimately can't actually happen on different CPUs so the lock won't be
contended.

johannes