> > > This is really theoretical question. Wireless has defined 4 > AC stream > > for simplicity so you map 2 TIDs out of 8 into 4 AC stream. One > > possible view of aggregation you don't map TID into AC > stream but run > > it along to get more fine grained. > > Otherwise why don't we do <AC, RA> but <TID,RA> . Just a possible > > view. after all it's mapped back to AC. > > Well 802.11 isn't really clear about this, it talks about > QSTAs having no more than one frame per <TID,RA,SA> > outstanding at a time. I don't have access to wi-fi documents > but I suspect they add further constraints because it's not > feasible to have that many packets buffered on the hardware. The aggregation is introduced in 802.11n and A-MPDU aggregation always comes together with block acknowledgement. The reason is that the component frames of an A-MPDU aggregate are individually subject to retransmission but not the aggregate itself. Block Acknowlegment allows to have a configurable number of outstanding packets (up to 128) which you can transmit before you require an acknowledgement. Therefore you also have to keep the packets for which you do not have already an acknowledgement. This is similar to TCP windows. Each block acknowledgement and aggregation process is identfied by the <TID, RA, SA> tuple. Having this ID has as a consequence that you have one sequence number counter for these packets, allowing the duplicate detection and retransmission. Maximum number of outstanding packets = 1 is only valid for the standard acknowledgement procedure (= one ack per packet). The AC has first hand only to do with the access priority to the air, but as a consequence the order of packets is only guaranteed within each AC. So each AC needs an individual TID and as a result an individual sequence number counter in order to do the duplicate detection. > > > I've looked into the Atheros driver, they way the implement > it is that when frames for an aggregation session are passed > to the ->tx() call they simply buffer them in software and > when they have enough they enqueue all of them to the > hardware queue for the particular AC they map into. This > scales much better, with 16 TIDs and many stations you can > that way possibly support a lot of concurrent aggregation sessions. > > Anyway, I'm confident you can work it out, I don't have time > any more for it right now, as I'll announce in a separate > email. I had a patch that mostly went the "just have queues > per AC" route, but it was incomplete, if anybody wants to > take a look it's at > http://johannes.sipsolutions.net/patches/kernel/all/2008-08-04 > -12%3a26/006-fix-skb-cb-agg.patch > > Here's a recap of the current issues that I'm aware of: > > * select_queue cannot really look into any state because due to > the lack of a single TX lock there's nothing to prevent it > racing against the code starting/stopping the aggregation > * you cannot re-queue and assume that skb->cb will be > left intact, > but that's codified now by clearing skb->cb on > master_start_xmit > * the current implementation of ieee80211_requeue is > racy against > select_queue, select_queue is called under RCU lock though so > you can use synchronize_rcu to avoid the race, this requires > moving ieee80211_requeue into process context though > > johannes > The atheros way is for sure possible but it comes with some constraints in building the aggregates. a) You can not dynamically adapt the A-MPDU to the remaining TXOP. b) You need to start a retransmission process of the aggregate packets in the AC queue immediatly, because otherwise you cannot release the buffers. Regards Friedrich -- 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
