> well, this bit just tells the driver that this frame should be > aggregated. it does not, in any case, determines to low-level driver > what will be be distribution of frames per A-MPDU or the order of > them, as this is the low-level's driver/HW job. so i believe Braodcom > can do what iwlwifi do, just check this bit and decide if they > aggregate the frame or not, and in which A-MPDU. the rest of the > information needed can be extracted easily from start/stop aggregation > flows. Oh, you're right, mac80211 doesn't do that decision, the driver will have to do it. > I can change this book keeping, though current solution provides us up > to 32 HW queues, which is really a huge amout of queues in terms of > HW. if needed after all, i would prefer to do it on top of this > series. Well you don't really need to change any code I think, only use unsigned long qdisc_pool[BITS_TO_LONGS(NUM_TX_DATA_QUEUES_AMPDU)]; instead and that way we should already be safe for future increases of the NUM_TX_DATA_QUEUES_AMPDU value. set_bit/clear_bit/etc. are already prepared to handle such an array so I'd prefer to have it right away just so there are less gotchas when that happens. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
