> There is no use of QoS and HT without NET_SCHD so we should not > announce support for HT or QoS in that configuration Ok. Ron, can you maybe make a patch? You're more familiar with where the HT hooks are and where stuff would have to be optional. Unless of course [see below] > but I'm not sure > if it's worth the effort to compile mac80211 without NET_SCHED. Maybe we just want to make mac80211 depend on NET_SCHED then? I personally think that is a good thing since otherwise drivers will also have to have code that depends on NET_SCHED for QoS features etc. > The number or aggregated frames in AMPDU is determined by handshake > maximum is 64 > IIRC but also dynamically but how many frames fits into TXOP and this > is also function of how fast are packets brought the HW Right. > > In any case, I think this confirms my idea of splitting up the "queues" > > hardware specific value into "queues" and "ampdu_queues" where "queues" > > are the number of FIFOs with QoS parameters and "ampdu_queues" are the > > number of helper DMA queues for ampdu support. > > That would fit perfectly Ok, let's do that then as in the WIP patch I had posted. > Broadcom doesn't seem to > > use extra DMA queues for this, the aggregation decisions are (afaik > > since the hw has no extra queues I can find) all made in the driver. I > > suppose b43 will then have to fake a reasonable number of "ampdu_queues" > > and handle it in the driver. > > Not sure how retransmission is handled. Where a packet sits when it > fails transmission in the single aggregation... that would be a major > concern. TBH, I don't know yet. > > > The limited number of queues is acceptable again due to fact that > > > medium is shared and you cannot really utilize too many BA ssessions > > > at the same time. Some policy of eviction based on link quality is > > > required and still not implemented. > > > > Expected traffic too, I would think, no? If the traffic from/to a > > specific station drops below a threshold I would expect to tear down the > > BA session. > > That's what we would do part of rate scaling... currently only the > establishment is done not tear down. Right, it should be part of rate control. Just trying to understand what should happen. > Hope we soon free our schedule to push this little. :) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
