On Wed, Jul 30, 2008 at 4:19 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > >> 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? I'm think your miss understanding is that HW FIFO != HW QUEUE. HW FIFO takes gives fairness in level of AC.. HW QUEUE just piles up packets for HW scheduler. qdisc should be just provide simple buffering 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
