Re: mac80211: net_sched vs. HT

[Johannes Berg <johannes@sipsolutions.net>]

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


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