Re: iwlwifi aggregation info

["Tomas Winkler" <tomasw@gmail.com>]

On Wed, Jul 30, 2008 at 4:19 PM, Johannes Berg
<johannes@sipsolutions.net> 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