On Tue, Feb 26, 2008 at 12:55 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > 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. I'm not sure about this, this is quite gentle and requires heavy testing. I'll try to review this with Ron tomorrow and all other changes you've suggested. Do you have any setup to check your these changes? Currently there is known possible deadlock when unloading driver while heavy HT traffic. This is happening while treering down BA session. I need to solve this as well. Thanks Tomas - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
