On Thu, 2008-10-23 at 15:01 +0530, Sujith wrote: > Johannes Berg wrote: > > It seems that should be a rate control decision? Possibly taking into > > account more than just always doing aggregation sessions. Then again, I > > suppose aggregation sessions are cheap. What about latency here? > > > > Well, that is what Luis seems to think too, but our RC > doesn't do much now, so we try to setup an aggregation session with any > associated STA. If that was done in the RC at least (could easily be moved I suppose) and you cleaned up the RC, then surely nbd would play with porting minstrel and making it aware of such things, which probably makes for a better RC... And since you have to clean up the RC anyway :) > > "maintain minimum HW queue depth"? In what way? You mean put in enough > > frames? > > I was talking about this: > (txq->axq_depth < ATH_AGGR_MIN_QDEPTH) in ath_tx_sched_aggr()@xmit.c But what does this invariant mean? ATH_AGGR_MIN_QDEPTH is 2. > > > Well, I really don't know how this would affect performance, but > > > I think this _might_ be a better model. > > > > Where would you see it have a noticeable effect on performance? > > How would mac80211 buffer frames ? Well I suppose it would just put them on a list in the sta_info struct. > Would it wait for enough sub-frames > to fill an A-MPDU ? It should, no? And if for some reason that doesn't happen fast enough it can send them out anyway, it'll just be a shorter A-MPDU, no? > When does it decide that buffered frames have to > be pushed down to the driver ? When the A-MPDU is full, subject to the TX and RX constraints, or when too much time has passed maybe? I really don't know. But I'd like to get to a model where we can implement other drivers without having to keep track of all this like ath9k does. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
