> I don't really follow your question. The dummy functions in wme.h for > wme were there before we added only ht functions. Yes I know. > WME i.e. QoS is not defined when NET_SCHED is not defined. This is > more for code completeness then for anything else, in fact with do not > compile mac80211 without NET_SCHED support > Valid QoS STA is when there is QoS association and support 4 AC, etc Yes but we still fill in WMM information elements and announce QoS support w/o NET_SCHED which seems to be wrong, especially with HT. That's what I was trying to get at. Should that be dependent on NET_SCHED? I think it should so that we don't announce QoS/HT support when we don't have QoS in the kernel. > AMPDU queues and also 4 AC queues are after all funneled to 4 AC lower > level queues we called them TX FIFOS, which are configured according > QoS parameters (not upper queues, but that's transparent). The major > purpose of AMPDU queue is handling reordering not AC. Right, that's what I thought. I guess the decision on how many frames to aggregate in a single AMPDU is made by firmware then? Doesn't really matter anyway. 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. 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. > In general for example in AP mode you would need to handle <number of > associated station>x<#TID=8> AMPDU queues which can come to a horrible > number. > 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. > > --- > > drivers/net/wireless/adm8211.c | 7 - > > drivers/net/wireless/ath5k/base.c | 10 +- > > drivers/net/wireless/ath5k/base.h | 4 > > drivers/net/wireless/b43/dma.c | 15 +-- > > drivers/net/wireless/b43/main.c | 3 You really could have snipped the patch out. Please? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
