> from my understanding the reason for hardware aggregation > queues is not a different priority level as for the AC queues. > But there are two things that make hardware aggregation queues > reasonable: > > a) Packets which are aggregated must be in sequence and they > must belong to the same RA/TID. So if you mix packets which > belong to that aggregation process with packets which do no > not belong to that RA/TID, then you must either break the > aggregation process or you must somehow "jump" over the > packets to find suitable canditates for aggregation. Yes, I know this. > I think a random access to a queue makes it really > difficult to handle the hardware queues as it is done > today, because today it is assumed that packets are > dequeued in the order in that they are enqueued. > > Therefore it is more likely that you have to break the > aggregation process when you find a packet that does not > fit to the current aggregation process. Well other drivers would have to handle the aggregation in software, obviously, and only put the packets onto the queue once enough have been collected. I'm fairly do understand what's going on. How does the hardware make the scheduling decision between the regular and a-mpdu queue? If it sends out a bunch of aggregated frames whenever there are enough, how is that _not_ unfair to non-agg stations? The way I would implement it (and I guess atheros/broadcom do) is to queue up frames for a station like NAPI does: either for a certain time (low traffic, and ampdu will be disabled again) or until the txop window is full, and then queue all of them to the right fifo/hw queue. Which, in my software design, simply means deferring them a bit inside the driver. Or for your driver, sticking them into a separate queue. But if they don't come in via the same qdisc, I don't see how it can be fair. Please let's get the upper layer considerations before we talk about the implementation though. Do you not agree that giving an aggregation flow a separate qdisc is unfair within that AC? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
