On Wed, Sep 02, 2009 at 04:07:03PM +0200, Patrick McHardy wrote:
quoted text
> Eric Dumazet wrote:
> > Patrick McHardy a écrit :
> >> Eric Dumazet wrote:
> >>> [PATCH net-next-2.6] tc: report informations for multiqueue devices
> >>>
> >>> qdisc and classes are not yet displayed by "tc -s -d {qdisc|class} show"
> >>> for multiqueue devices.
> >>>
> >>> We use a new TCA_QINDEX attribute, to report queue index to user space.
> >>> iproute2 tc should be changed to eventually display this queue index as in :
> >>>
> >>> $ tc -s -d qdisc
> >>> qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> >>>  Sent 52498 bytes 465 pkt (dropped 0, overlimits 0 requeues 0)
> >>>  rate 0bit 0pps backlog 0b 0p requeues 0
> >>> qdisc pfifo_fast 0: dev eth0 qindex 1 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
> >>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> >>>  rate 0bit 0pps backlog 0b 0p requeues 0
> >> This might confuse existing userspace since the handle is not unique
> >> anymore. libnl f.i. will treat all but the first root qdisc as an
> >> update and use it to update the state of the first one. There's also
> >> no combined view for applications unaware of multiqueue.
> >>
> >> Please have a look at the mail I just wrote for some possible ways
> >> around this.
> > 
> > Hum, how can we combine infos on qdisc/class if in the future we allow each queue index
> > to have its own qdisc/classes ?
> > 
> > htb on queue index 0
> > cbq on queue index 1
> 
> My suggestion was to only dump the statistics in the combined
> view and use a virtual qdisc, something like:
> 
> qdisc multiqueue 0: dev eth0 root queues 8
>   Sent ...
>   rate ...
> 
> and show each real qdisc as child of this qdisc:
> 
> qdisc pfifo_fast <unique handle> dev eth0 parent 0: bands 3 ...
> qdisc pfifo_fast <unique handle> dev eth0 parent 0: bands 3 ...
> 
> Configuration would be symetrical to this:
> 
> tc qdisc add dev eth0 handle 0: root multiqueue
> tc qdisc add dev eth0 handle x: parent 0: pfifo_fast
> ...

Actually, I wonder why it can't be a real "virtual" qdisc with
classes, similar to... multiq, doing such mappings inside, according
to the current api:

tc qdisc add dev eth0 handle 1: root multiqueue
tc qdisc add dev eth0 handle x: parent 1:1 pfifo_fast

Jarek P.

PS: but I'd prefer (more) different name, even mq, mtq or something.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html