On Fri, Aug 1, 2008 at 3:54 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2008-08-01 at 15:40 +0300, Tomas Winkler wrote: >> > 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. So this is the most important point of this conversation... What do you call this beast! What I'm trying to say all the way along I don't need qdisc per se I need like 80% of it. So it was already implemented in qdisc so it was utilized. I'm not aware of anything else that is already implemented but you can always open my eyes and I'm not trying to be cynical. > >> >> 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. 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. >> 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. True but there is s always some sane default. > > > 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? You are looking at the wrong point. All stations got fair amount of air space according AC and TXOP but then number of bytes that are transmitted is different. While the slow station will use this time to transfer packet on low rate with many retries faster station will fill it with many bytes at high rates.I hope it's clear that fixed rate video stream is not implies wireless rate. I believe the upper level in this case will take flow control decision and release packet pressure on the slow station. > 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. Exactly, but if you don't have mechanism to fill up the TXOP efficiently such as have packets ready in a separate queue it just won't fly. ------- I suggest to start at some more productive point. So what is important is that we agree on one thing that we need sw queue/buffer (forget qdisc for now) for aggregation queue and the question is how to implement it efficiently and how to resolve cleanly the lack of requeueing in the new MQ. . ------- Thanks 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
