On Fri, 2008-08-01 at 15:40 +0300, Tomas Winkler wrote: > >> > Right. Which brings us back to the original point, why does the hw need > >> > to make the scheduling decision between agg and non-agg? > >> > >> There is no scheduling between aag and legacy queue in the sense of > >> qdisc . > > > > Right. So why are you saying we should have a separate qdisc for it? > > I need a sw queue for it. Sure, you need to buffer packets, but that's a whole different beast. > >> The aggregation need to be taken from single stream as > >> explained before, > > > > I think we simply agree on that. Which brings me back to my original > > point: to provide fairness within that stream we shouldn't have separate > > qdiscs for agg/non-agg parts of the stream. > > You agree on the fact that it's a seperate stream but you still > doesn't want separate queue for it.... Actually, no, I don't think it's a separate stream, I think aggregation frames are taken from the AC stream. I thought you meant that. > >> Iwlwifi has HW support for it that that's the whole story we just need > >> queueing support from the software buffering stopping and starting > >> queue and last but not least there is a classification just an > >> extension of the regular AC scheduling. The fairness between legacy > >> and agg queue must be provided by actually 'not scheduling' > > > > I don't understand what you mean by "not scheduling". > > Not scheduling mean not string to prioritize streams in SW. I guess it means RR. But that's entirely user dependent if we allow actual qdiscs. > AIUI from the > > specs, there is no scheduling between aggregation/non-aggregation > > queues, or "within an AC" as I would say it. > > > > Therefore, I think we should remove the extra software queues and split > > up the single-AC stream into the different hardware queues in the > > driver, to be reunited in the FIFOs. > > Aggregation is a separate stream even on the air it has it's own > rhythm. For example > from AP perspective you an have 3 streams for the same TID for 3 > stations. Each station > has it's own rate of processing aggregation stream. It may vary on > number of packets and size of the aggregation > this is determine in association time. > So shell I stop the whole AC queue just because on station is slower? If you want to draw up scenarios here, how about this one: From an AP perspective, assume three streams for the same TID for three stations. No aggregation involved. Say they all receive a fixed bitrate video stream. Assume you need all the airtime to transmit the three video streams when all stations are fairly close. Now one of them is further away and is a bit slower than the others. This will lead to contention, right? So now, frames will queue up in the AC queue for this TID, penalising all three stations. Do you agree so far? Now, enter aggregation. The way I think of it (and Jouni seems to agree) is that the spec intended for aggregation to be a mechanism to reduce the required airtime by making the transmission more efficient with less space. On the other hand, you seem to think of aggregation as a QoS mechanism, and I think that's wrong. Ideally, for the first two fast stations would allow enough airtime to be freed up so that the third station can still receive the video stream. When that is not the case, however, we disagree. I think that because aggregation isn't a QoS mechanism, it should behave the same way as in the case where no stations have aggregation enabled, and stall the whole queue. On the other hand, you think it is a QoS mechanism, and let streams for the fast stations be interleaved with the slow station, leaving only frames for the slow station piling up. Is my analysis of what you are saying correct? If so, I think we cannot solve the fundamental disagreement here without actually going and asking for other people's opinion on the 11n draft. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
