Re: [RFC PATCH] bcm43xx QoS support

[Johannes Berg <johannes@sipsolutions.net>]

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

On Sun, 2007-06-17 at 02:30 +0300, Tomas Winkler wrote:

> > > There is also a discussion about supporting hardware queues in qdisc
> > > in netdev.
> >
> > Which isn't really a concern to the driver since only mac80211 will need
> > to be changed for that.
> >
> I'm not sure it's only mac80211 problem as driver is responsible for
> stopping and waking up the queues. Only driver knows whether hw queue
> is full or not.

Of course, but we already have that API in mac80211, hence well-written
drivers already tell mac80211 about it so all we'd need to do is change
mac80211 to tell the net layer :)

> > I suppose the question is: what are we missing in mac80211 now? It seems
> > that we have no way of sending out QoS-data frames and that seems weird..
> 
> QoS frame are send just fine by mac80211 (at least under iwlwifi),
> only the sequence numbers has to be overwritten in driver since the
> current handler doesn't advance them per TID.

Oh, you're right, I missed that wme_qdiscop_enqueue does that.

> > Nor do we parse TXOP information etc. Possibly this is because we
> > support WME and that's based on an early 802.11e draft?
> 
> I addition wme.c qdisc scheduler is rather naive one, it only
> statically assign priorities, it wouldn't pass WMM certification I
> guess.

I have no idea what WMM certification contains. All I've been trying to
say is that this area really needs some work to be useful.

For the problem at hand, namely some QoS support in bcm43xx, we'll just
have to hardcode some QoS parameters for now, I'd think, but I don't
know what those would be.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]