On Tue, 2008-02-26 at 00:50 +0200, Tomas Winkler wrote: > On Mon, Feb 25, 2008 at 10:46 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
