Re: mac80211: net_sched vs. HT

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2640 bytes --]


> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]