On Fri, Nov 16, 2012 at 09:36:21AM +0100, Arend van Spriel wrote: > On 11/15/2012 03:07 PM, Seth Forshee wrote: > >AMPDU session allows MPDUs to be temporarily queued until either a full > >AMPDU has been collected or circumstances dictate that transmission > >should start with a partial AMPDU. Packets are added to the session by > > I started reviewing this and reading this commit message got me > wondering about the .flush() problems. I realized the flush would be > a "circumstance" to start transmission of a partial AMPDU, but I am > pretty sure it currently is not treated as such. I hope my terminology here isn't confusing; I wasn't sure how else to express this. By "full" I mean an AMPDU that is transmitted because it can accommodate no more packets. A "partial" AMPDU is any that is transmitted without being full. One of the things I added when removing the tx queue was a DMA flush operation to force any queued AMPDU packets into the DMA ring. But in the current code brcms_c_sendampdu() will transmit the AMPDU with whatever it's got when it runs out of packets in the pktq, so I don't see a partial AMPDU problem. What does strike me as problematic is the locking in brcms_ops_flush(). It holds wl->lock, and the interrupt handling tries to acquire the same lock. Doesn't this prevent both the txpktpend counts from getting updated and any more packets being transmitted from the packet queue? Seth -- 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
