[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1320942369.3967.127.camel@jlt3.sipsolutions.net>
Date: Thu, 10 Nov 2011 17:26:09 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev <netdev@...r.kernel.org>,
linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: creating netdev queues on the fly?
On Thu, 2011-11-10 at 15:35 +0100, Eric Dumazet wrote:
> > So to get to my question: What if we could create netdev queues on the
> > fly?
> In term of qdisc management I believe its a bit complex if we start to
> dynamically add netdev queues :)
Yeah I was thinking that would be the problematic part.
> My first idea would be to extend Qdisc management so that a device can
> callback qdisc when a frame is finaly delivered / consumed / discarded.
>
> We currently only have qdisc->enqueue() and qdisc->dequeue(), we could
> add qdisc->deliver_callback(skb)
>
> You keep devices as they are, with a netdevqueue per hardware queue.
>
> Then, using a Qdisc like existing ones, but with a limit of
> outstanding(given to device but not yet consumed) packets per class.
>
> external tc classifier would deliver a hash/index depending on remote
> station.
So basically you'd have a class for each station? Or a class for each
station/AC? That's a lot of classes rather than queues, are they
pre-allocated, or does it not matter? Overall that sounds like a good
approach.
> As a bonus you can get all the existing rate estimators / QOS /
> shapers ...
Yeah ... I guess I need to start learning tc :)
johannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists