netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: UDP is bypassing qdisc statistics ....
  2009-08-31 21:46 UDP is bypassing qdisc statistics Christoph Lameter
@ 2009-08-31 19:54 ` Eric Dumazet
  2009-08-31 20:58   ` Mark Smith
  0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2009-08-31 19:54 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: netdev, davem

Christoph Lameter a écrit :
> This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
> packet by the qdisc layer:
> 
> #tc -s qdisc show
> 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 10491 bytes 72 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> 
> #ping yy
> PING yy (10.2.36.120) 56(84) bytes of data.
> 64 bytes from yy (10.2.36.120): icmp_seq=1 ttl=64 time=0.933 ms
> 64 bytes from yy (10.2.36.120): icmp_seq=2 ttl=64 time=0.122 ms
> 64 bytes from yy (10.2.36.120): icmp_seq=3 ttl=64 time=0.119 ms
> ^C
> --- yy ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
> rtt min/avg/max/mdev = 0.119/0.391/0.933/0.383 ms
> 
> #tc -s qdisc show
> 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 10839 bytes 75 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> 
> 
> Now I overrun the transmitter with udp multicast traffic:
> 
> #./mcast -n1 -r400000
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 0 MC addresses 239.0.192-254.2-254 offset 0
> origin 10.2.36.120
> Sender: Sending 400000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
> ^C
> Unsubscribing from multicast groups
> Done.
> 
> #tc -s qdisc show
> 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 13359 bytes 101 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0
> 
> 
> The mcast invocation send over 3 million packets(!) but they are not
> accounted for in the qdisc. 500k of those were lost. Also not counted.
> The 26 packets receives are likely only covering the ssh session using
> TCP.
> 
> Receiver log:
> 
> yy#./mcast
> Receiver: Listening to control channel 239.0.192.1
> Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 10.2.36.121
> 
> TotalMsg   Lost SeqErr TXDrop Msg/Sec  KB/Sec  Min/us  Avg/us  Max/us StdDv
>  3110416 531472  25555 531472  307958     0.0  151.45 1648.21 1875.68 499.92
> Unsubscribing from 1 multicast addresses origin 10.2.36.121.
> 
> What is wrong here? Is UDP bypassing the qdisc layer?
> 
> Tried UDP unicast with similar effects.


Not reproductible here, I can see bytes/pkts counts increasing while mcast -n1 -r400000 runs.

# tc -s -d qdisc show dev eth0 ; sleep 1 ; tc -s -d qdisc show dev eth0
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 7694155580 bytes 36894415 pkt (dropped 0, overlimits 0 requeues 2)
 rate 0bit 0pps backlog 0b 0p requeues 2
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 7778853932 bytes 37142071 pkt (dropped 0, overlimits 0 requeues 2)
 rate 0bit 0pps backlog 0b 0p requeues 2


Check :

# ip ro 
# ip ro get 10.2.36.120
# ip ro get 239.0.192.2

maybe your pings do use eth0, and your multicast doesnt.

loopback device do bypass qdisc layer for example...

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-08-31 19:54 ` Eric Dumazet
@ 2009-08-31 20:58   ` Mark Smith
  2009-09-01  6:37     ` Jarek Poplawski
  0 siblings, 1 reply; 21+ messages in thread
From: Mark Smith @ 2009-08-31 20:58 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Christoph Lameter, netdev, davem

On Mon, 31 Aug 2009 21:54:49 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Christoph Lameter a écrit :
> > This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
> > packet by the qdisc layer:
> > 
<snip>
> 
> loopback device do bypass qdisc layer for example...

On occassion, I'd have found it useful if it didn't. It'd be convenient
to test out your qdisc config, or test out applications performance
behaviour over a simulated WAN via netem, without having to a
network and two hosts, and all the related miscellaneous setup work.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* UDP is bypassing qdisc statistics ....
@ 2009-08-31 21:46 Christoph Lameter
  2009-08-31 19:54 ` Eric Dumazet
  0 siblings, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-08-31 21:46 UTC (permalink / raw)
  To: netdev; +Cc: davem, eric.dumazet

This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
packet by the qdisc layer:

#tc -s qdisc show
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 10491 bytes 72 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

#ping yy
PING yy (10.2.36.120) 56(84) bytes of data.
64 bytes from yy (10.2.36.120): icmp_seq=1 ttl=64 time=0.933 ms
64 bytes from yy (10.2.36.120): icmp_seq=2 ttl=64 time=0.122 ms
64 bytes from yy (10.2.36.120): icmp_seq=3 ttl=64 time=0.119 ms
^C
--- yy ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.119/0.391/0.933/0.383 ms

#tc -s qdisc show
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 10839 bytes 75 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0


Now I overrun the transmitter with udp multicast traffic:

#./mcast -n1 -r400000
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 0 MC addresses 239.0.192-254.2-254 offset 0
origin 10.2.36.120
Sender: Sending 400000 msgs/ch/sec on 1 channels. Probe interval=0.001-1 sec.
^C
Unsubscribing from multicast groups
Done.

#tc -s qdisc show
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 13359 bytes 101 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0


The mcast invocation send over 3 million packets(!) but they are not
accounted for in the qdisc. 500k of those were lost. Also not counted.
The 26 packets receives are likely only covering the ssh session using
TCP.

Receiver log:

yy#./mcast
Receiver: Listening to control channel 239.0.192.1
Receiver: Subscribing to 1 MC addresses 239.0.192-254.2-254 offset 0 origin 10.2.36.121

TotalMsg   Lost SeqErr TXDrop Msg/Sec  KB/Sec  Min/us  Avg/us  Max/us StdDv
 3110416 531472  25555 531472  307958     0.0  151.45 1648.21 1875.68 499.92
Unsubscribing from 1 multicast addresses origin 10.2.36.121.

What is wrong here? Is UDP bypassing the qdisc layer?

Tried UDP unicast with similar effects.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-08-31 20:58   ` Mark Smith
@ 2009-09-01  6:37     ` Jarek Poplawski
  2009-09-01  7:00       ` Eric Dumazet
  2009-09-01 18:03       ` Christoph Lameter
  0 siblings, 2 replies; 21+ messages in thread
From: Jarek Poplawski @ 2009-09-01  6:37 UTC (permalink / raw)
  To: Mark Smith; +Cc: Eric Dumazet, Christoph Lameter, netdev, davem

On 31-08-2009 22:58, Mark Smith wrote:
> On Mon, 31 Aug 2009 21:54:49 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>> Christoph Lameter a écrit :
>>> This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
>>> packet by the qdisc layer:
>>>
> <snip>
>> loopback device do bypass qdisc layer for example...
> 
> On occassion, I'd have found it useful if it didn't. It'd be convenient
> to test out your qdisc config, or test out applications performance
> behaviour over a simulated WAN via netem, without having to a
> network and two hosts, and all the related miscellaneous setup work.

Probably Eric and you mean something special, but generally a loopback
and some other virtuals bypass qdisc layer only with default qdisc.

Jarek P.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01  6:37     ` Jarek Poplawski
@ 2009-09-01  7:00       ` Eric Dumazet
  2009-09-01  9:37         ` Mark Smith
  2009-09-01 18:03       ` Christoph Lameter
  1 sibling, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01  7:00 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: Mark Smith, Christoph Lameter, netdev, davem

Jarek Poplawski a écrit :
> On 31-08-2009 22:58, Mark Smith wrote:
>> On Mon, 31 Aug 2009 21:54:49 +0200
>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>> Christoph Lameter a écrit :
>>>> This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
>>>> packet by the qdisc layer:
>>>>
>> <snip>
>>> loopback device do bypass qdisc layer for example...
>> On occassion, I'd have found it useful if it didn't. It'd be convenient
>> to test out your qdisc config, or test out applications performance
>> behaviour over a simulated WAN via netem, without having to a
>> network and two hosts, and all the related miscellaneous setup work.
> 
> Probably Eric and you mean something special, but generally a loopback
> and some other virtuals bypass qdisc layer only with default qdisc.
> 

Yes, I was referring to Christoph use, since on its machine, only
output from "tc -s -d qdisc" is about eth0


Mark, you can certainly do something like

# tc qdisc del dev lo root
# tc qdisc add dev lo root netem delay 100ms 10ms

# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
2009/08/01 08:59:22.799 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=204 ms
2009/08/01 08:59:23.804 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=208 ms
2009/08/01 08:59:24.801 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=204 ms
2009/08/01 08:59:25.808 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=209 ms

# tc -s -d qdisc show dev lo
qdisc netem 8001: root limit 1000 delay 100.0ms  10.0ms
 Sent 1764 bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01  7:00       ` Eric Dumazet
@ 2009-09-01  9:37         ` Mark Smith
  0 siblings, 0 replies; 21+ messages in thread
From: Mark Smith @ 2009-09-01  9:37 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Jarek Poplawski, Mark Smith, Christoph Lameter, netdev, davem

Hi Eric,

On Tue, 01 Sep 2009 09:00:46 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Jarek Poplawski a écrit :
> > On 31-08-2009 22:58, Mark Smith wrote:
> >> On Mon, 31 Aug 2009 21:54:49 +0200
> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>
> >>> Christoph Lameter a écrit :
> >>>> This is with 2.6.31-rc7. If I send icmp then its correctly registered as a
> >>>> packet by the qdisc layer:
> >>>>
> >> <snip>
> >>> loopback device do bypass qdisc layer for example...
> >> On occassion, I'd have found it useful if it didn't. It'd be convenient
> >> to test out your qdisc config, or test out applications performance
> >> behaviour over a simulated WAN via netem, without having to a
> >> network and two hosts, and all the related miscellaneous setup work.
> > 
> > Probably Eric and you mean something special, but generally a loopback
> > and some other virtuals bypass qdisc layer only with default qdisc.
> > 
> 
> Yes, I was referring to Christoph use, since on its machine, only
> output from "tc -s -d qdisc" is about eth0
> 
> 
> Mark, you can certainly do something like
> 
> # tc qdisc del dev lo root
> # tc qdisc add dev lo root netem delay 100ms 10ms
> 
> # ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 2009/08/01 08:59:22.799 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=204 ms
> 2009/08/01 08:59:23.804 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=208 ms
> 2009/08/01 08:59:24.801 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=204 ms
> 2009/08/01 08:59:25.808 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=209 ms
> 
> # tc -s -d qdisc show dev lo
> qdisc netem 8001: root limit 1000 delay 100.0ms  10.0ms
>  Sent 1764 bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
>  rate 0bit 0pps backlog 0b 0p requeues 0

Either I tested it a couple of years back and you couldn't assign a
qdisc to loopback, and/or I read somewhere that the loopback driver was
highly optimised for looping packets back, and assumed that meant that
it bypassed the qdisc layer. 

Oh well, that's great that it already does what I was asking for.

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 18:03       ` Christoph Lameter
@ 2009-09-01 14:20         ` Patrick McHardy
  2009-09-01 14:58           ` Eric Dumazet
                             ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Patrick McHardy @ 2009-09-01 14:20 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Eric Dumazet, Mark Smith, Jarek Poplawski, netdev, davem

Christoph Lameter wrote:
> Eric: This occurs with a Broadcom driver (bnx2). There is only one
> network device up and the IP statistics are correctly incremented.

That explains it. The bnx2 driver uses multiple TX queues, but
tc_dump_qdisc() only dumps the statistics from queue number 0.

Not sure whether we should sum them up or dump the statistics
from each queue (or both). Summing them up avoids userspace
visible changes when drivers are converted to multiq.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 14:20         ` Patrick McHardy
@ 2009-09-01 14:58           ` Eric Dumazet
  2009-09-01 19:05             ` Christoph Lameter
  2009-09-01 18:29           ` Christoph Lameter
  2009-09-01 19:30           ` Christoph Lameter
  2 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01 14:58 UTC (permalink / raw)
  To: Patrick McHardy
  Cc: Christoph Lameter, Mark Smith, Jarek Poplawski, netdev, davem

Patrick McHardy a écrit :
> Christoph Lameter wrote:
>> Eric: This occurs with a Broadcom driver (bnx2). There is only one
>> network device up and the IP statistics are correctly incremented.
> 
> That explains it. The bnx2 driver uses multiple TX queues, but
> tc_dump_qdisc() only dumps the statistics from queue number 0.
> 
> Not sure whether we should sum them up or dump the statistics
> from each queue (or both). Summing them up avoids userspace
> visible changes when drivers are converted to multiq.

Ok mystery solved, partially at least :)

Hmm, my bnx2 still displays correct info here (BCM5708S) ; so maybe Christoph has a
real multiqueue NIC adapter ? I thought he mentioned a mono queue NIC earlier.

Dumping stats for each queue would be better for admin point of view IMHO
(restricted to real_num_tx_queues I guess, since bnx2 allocates 8 queues per device.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 19:05             ` Christoph Lameter
@ 2009-09-01 15:28               ` Eric Dumazet
  2009-09-01 19:35                 ` Christoph Lameter
  0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01 15:28 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev, davem

Christoph Lameter a écrit :
> On Tue, 1 Sep 2009, Eric Dumazet wrote:
> 
>> Hmm, my bnx2 still displays correct info here (BCM5708S) ; so maybe Christoph has a
>> real multiqueue NIC adapter ? I thought he mentioned a mono queue NIC earlier.
> 
> I have no clue if it is or not. I have never used those features.
> 
> dmesg says:
> 
> Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express
> 
> Is that a multiqueue adapter?

You should see that in /proc/interrupts, if I correctly understand bnx2.c

Just to be sure :
With following patch I got in my syslog :

[    8.789048] rx_rings=1 real_num_tx_queues=1
[    9.005700] rx_rings=1 real_num_tx_queues=1

So my bnx2 is mono-queue :(


diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 06b9011..573d6b3 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6144,6 +6144,7 @@ bnx2_setup_int_mode(struct bnx2 *bp, int dis_msi)
 	bp->dev->real_num_tx_queues = bp->num_tx_rings;

 	bp->num_rx_rings = bp->irq_nvecs;
+	pr_err("rx_rings=%d real_num_tx_queues=%d\n", bp->num_rx_rings,  bp->num_tx_rings);
 }

 /* Called with rtnl_lock */



^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 19:30           ` Christoph Lameter
@ 2009-09-01 15:34             ` Eric Dumazet
  0 siblings, 0 replies; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01 15:34 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev, davem

Christoph Lameter a écrit :
> On Tue, 1 Sep 2009, Patrick McHardy wrote:
> 
>> That explains it. The bnx2 driver uses multiple TX queues, but
>> tc_dump_qdisc() only dumps the statistics from queue number 0.
> 
> There are no stats in other queues either... This is the result after
> sending 10000 or so packets. Maybe I am not catching all the qdiscs?
> 
> (this is the result of a pretty raw patch to dump all qdiscs)
> 
> #cat /proc/net/qdisc_stats
> Type Device State Bytes Packets Qlen Backlog Drops Requeues Overlimits
> TX root <NULL> 0 0 0 0 0 0 0 0
> RX root <NULL> 0 0 0 0 0 0 0 0
> TX root  eth0 0 24830 155 0 0 0 0 0
> RX root <NULL> 0 0 0 0 0 0 0 0
> TX root <NULL> 0 0 0 0 0 0 0 0
> RX root <NULL> 0 0 0 0 0 0 0 0
> TX root <NULL> 0 0 0 0 0 0 0 0
> RX root <NULL> 0 0 0 0 0 0 0 0
> TX root <NULL> 0 0 0 0 0 0 0 0
> RX root <NULL> 0 0 0 0 0 0 0 0
> 
> ---
>  net/sched/sch_api.c |   64 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
> 
> Index: linux-2.6/net/sched/sch_api.c
> ===================================================================
> --- linux-2.6.orig/net/sched/sch_api.c	2009-08-31 21:19:04.000000000 +0000
> +++ linux-2.6/net/sched/sch_api.c	2009-09-01 14:30:40.000000000 +0000
> @@ -1699,6 +1699,69 @@ static const struct file_operations psch
>  	.llseek = seq_lseek,
>  	.release = single_release,
>  };
> +
> +static void dump_qdisc(struct seq_file *seq, struct Qdisc *q, char *inout, char *text)
> +{
> +	seq_printf(seq, "%2s %2s %5s %lx %lld %d %d %d %d %d %d\n",
> +		inout, text, q->dev_queue->dev->name, q->state,
> +		q->bstats.bytes, q->bstats.packets,
> +		q->qstats.qlen, q->qstats.backlog, q->qstats.drops,
> +		q->qstats.requeues, q->qstats.overlimits);
> +}
> +
> +static void dump_qdisc_root(struct seq_file *seq, struct Qdisc *root, char *inout)
> +{
> +	struct Qdisc *q;
> +	int n = 0;
> +
> +	if (!root)
> +		return;
> +
> +	dump_qdisc(seq, root, inout, "root");
> +
> +	list_for_each_entry(q, &root->list, list) {
> +		char buffer[10];
> +
> +		sprintf(buffer,"%d", ++n);
> +		dump_qdisc(seq, q, inout, buffer);
> +	}
> +}
> +
> +
> +static int qdisc_show(struct seq_file *seq, void *v)
> +{
> +	struct net_device *dev;
> +
> +	seq_printf(seq, "Type Device State Bytes Packets "
> +			"Qlen Backlog Drops Requeues Overlimits\n");
> +
> +	read_lock(&dev_base_lock);
> +
> +	for_each_netdev(&init_net, dev) {
> +		struct netdev_queue *dev_queue;
> +
> +		dev_queue = netdev_get_tx_queue(dev, 0);
> +		dump_qdisc_root(seq, dev_queue->qdisc_sleeping, "TX");

you should iterate here 

	for (i = 0 ; i < dev->real_num_tx_queues; i++) {
		dev_queue = netdev_get_tx_queue(dev, i);
		dump_qdisc_root(seq, dev_queue->qdisc_sleeping, "TX");
	}


> +		dev_queue = &dev->rx_queue;
> +		dump_qdisc_root(seq, dev_queue->qdisc_sleeping, "RX");
> +	}
> +
> +	read_unlock(&dev_base_lock);
> +	return 0;
> +}
> +
> +static int qdisc_open(struct inode *inode, struct file *file)
> +{
> +	return single_open(file, qdisc_show, PDE(inode)->data);
> +}
> +
> +static const struct file_operations qdisc_fops = {
> +	.owner = THIS_MODULE,
> +	.open = qdisc_open,
> +	.read = seq_read,
> +	.llseek = seq_lseek,
> +	.release = single_release,
> +};
>  #endif
> 
>  static int __init pktsched_init(void)
> @@ -1706,6 +1769,7 @@ static int __init pktsched_init(void)
>  	register_qdisc(&pfifo_qdisc_ops);
>  	register_qdisc(&bfifo_qdisc_ops);
>  	proc_net_fops_create(&init_net, "psched", 0, &psched_fops);
> +	proc_net_fops_create(&init_net, "qdisc_stats", 0, &qdisc_fops);
> 
>  	rtnl_register(PF_UNSPEC, RTM_NEWQDISC, tc_modify_qdisc, NULL);
>  	rtnl_register(PF_UNSPEC, RTM_DELQDISC, tc_get_qdisc, NULL);


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 19:35                 ` Christoph Lameter
@ 2009-09-01 15:43                   ` Eric Dumazet
  2009-09-01 15:58                     ` Eric Dumazet
  0 siblings, 1 reply; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01 15:43 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev

Christoph Lameter a écrit :
> On Tue, 1 Sep 2009, Eric Dumazet wrote:
> 
>> You should see that in /proc/interrupts, if I correctly understand bnx2.c
> 
> Hmmm I have 8 interrupts:
> 
>   62:        158          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-0
>   63:         84          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-1
>   64:        412          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-2
>   65:         25          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-3
>   66:      49718          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-4
>   67:         65          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-5
>   68:        686          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-6
>   69:       2582          0          0          0          0          0
> 0          0          0          0          0          0          0
> 0          0          0  IR-PCI-MSI-edge      eth0-7

Yes, this confirm you have 8 queues on this NIC

Strange thing is they seem to be all serviced by CPU-0, which is not good...



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 15:43                   ` Eric Dumazet
@ 2009-09-01 15:58                     ` Eric Dumazet
  2009-09-01 20:13                       ` Christoph Lameter
  2009-09-01 21:55                       ` Christoph Lameter
  0 siblings, 2 replies; 21+ messages in thread
From: Eric Dumazet @ 2009-09-01 15:58 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev

Eric Dumazet a écrit :
> Christoph Lameter a écrit :
>> On Tue, 1 Sep 2009, Eric Dumazet wrote:
>>
>>> You should see that in /proc/interrupts, if I correctly understand bnx2.c
>> Hmmm I have 8 interrupts:
>>
>>   62:        158          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-0
>>   63:         84          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-1
>>   64:        412          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-2
>>   65:         25          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-3
>>   66:      49718          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-4
>>   67:         65          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-5
>>   68:        686          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-6
>>   69:       2582          0          0          0          0          0
>> 0          0          0          0          0          0          0
>> 0          0          0  IR-PCI-MSI-edge      eth0-7
> 
> Yes, this confirm you have 8 queues on this NIC
> 
> Strange thing is they seem to be all serviced by CPU-0, which is not good...
> 
> 
> 

Given that bnx2.c uses num_online_cpus() at init time, you could
as a workaround do the insmod/modprobe bnx2 with only one online cpu,
and you'll revert to a mono-queue NIC :)

int msix_vecs = min(cpus + 1, RX_MAX_RINGS); 
...
if ((bp->flags & BNX2_FLAG_MSIX_CAP) && !dis_msi && cpus > 1)
	bnx2_enable_msix(bp, msix_vecs);


For your multicast test anyway, only one queue should be used (one flow)



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01  6:37     ` Jarek Poplawski
  2009-09-01  7:00       ` Eric Dumazet
@ 2009-09-01 18:03       ` Christoph Lameter
  2009-09-01 14:20         ` Patrick McHardy
  1 sibling, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 18:03 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Mark Smith, Jarek Poplawski, netdev, davem

Eric: This occurs with a Broadcom driver (bnx2). There is only one
network device up and the IP statistics are correctly incremented.

#ip ro
10.2.36.0/24 dev eth0  proto kernel  scope link  src 10.2.36.121
default via 10.2.36.3 dev eth0
#ip ro get 10.2.36.120
10.2.36.120 dev eth0  src 10.2.36.121
    cache  mtu 1500 advmss 1460 hoplimit 64
ip ro get 239.0.192.2
multicast 239.0.192.2 dev eth0  src 10.2.36.121
    cache <mc>  mtu 1500 advmss 1460 hoplimit 64

dmesg:

[    1.560094] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.0.1
(May 6, 2009)
[    1.560192]   alloc irq_desc for 36 on node 0
[    1.560193]   alloc kstat_irqs on node 0
[    1.560197] alloc irq_2_iommu on node 0
[    1.560204] bnx2 0000:01:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ
36
[    1.560275] bnx2 0000:01:00.0: setting latency timer to 64
[    1.560394] bnx2 0000:01:00.0: firmware: requesting
bnx2/bnx2-mips-09-4.6.17.fw


$ netstat -su
IcmpMsg:
    InType0: 4
    InType3: 1
    OutType3: 1
    OutType8: 4
Udp:
    44363 packets received
    0 packets to unknown port received.
    0 packet receive errors
    4363620 packets sent
    SndbufErrors: 738519
UdpLite:
IpExt:
    InMcastPkts: 1289
    OutMcastPkts: 5057780
    InOctets: 13956676
    OutOctets: 1672676365
    InMcastOctets: 36164
    OutMcastOctets: 1658949880

(Your patch to account for TX errors was applied)

clameter@rd-gateway3-deb64:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:21:9b:8f:9f:1b
          inet addr:10.2.36.121  Bcast:10.2.36.255  Mask:255.255.255.0
          inet6 addr: fe80::221:9bff:fe8f:9f1b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:50091 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4367178 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:14928488 (14.2 MiB)  TX bytes:1509122809 (1.4 GiB)
          Interrupt:36 Memory:d6000000-d6012800

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:89 errors:0 dropped:0 overruns:0 frame:0
          TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:7114 (6.9 KiB)  TX bytes:7114 (6.9 KiB)




^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 14:20         ` Patrick McHardy
  2009-09-01 14:58           ` Eric Dumazet
@ 2009-09-01 18:29           ` Christoph Lameter
  2009-09-01 19:30           ` Christoph Lameter
  2 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 18:29 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Eric Dumazet, Mark Smith, Jarek Poplawski, netdev, davem

On Tue, 1 Sep 2009, Patrick McHardy wrote:

> Christoph Lameter wrote:
> > Eric: This occurs with a Broadcom driver (bnx2). There is only one
> > network device up and the IP statistics are correctly incremented.
>
> That explains it. The bnx2 driver uses multiple TX queues, but
> tc_dump_qdisc() only dumps the statistics from queue number 0.
>
> Not sure whether we should sum them up or dump the statistics
> from each queue (or both). Summing them up avoids userspace
> visible changes when drivers are converted to multiq.

Well I have almost finished a /proc/net/qdisc_stats that shows *all*
qdisc queues. Did this primarily for debugging since I do not know too
much about the netlink stuff.



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 14:58           ` Eric Dumazet
@ 2009-09-01 19:05             ` Christoph Lameter
  2009-09-01 15:28               ` Eric Dumazet
  0 siblings, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 19:05 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev, davem

On Tue, 1 Sep 2009, Eric Dumazet wrote:

> Hmm, my bnx2 still displays correct info here (BCM5708S) ; so maybe Christoph has a
> real multiqueue NIC adapter ? I thought he mentioned a mono queue NIC earlier.

I have no clue if it is or not. I have never used those features.

dmesg says:

Broadcom NetXtreme II BCM5709 1000Base-T (C0) PCI Express

Is that a multiqueue adapter?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 14:20         ` Patrick McHardy
  2009-09-01 14:58           ` Eric Dumazet
  2009-09-01 18:29           ` Christoph Lameter
@ 2009-09-01 19:30           ` Christoph Lameter
  2009-09-01 15:34             ` Eric Dumazet
  2 siblings, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 19:30 UTC (permalink / raw)
  To: Patrick McHardy; +Cc: Eric Dumazet, Mark Smith, Jarek Poplawski, netdev, davem

On Tue, 1 Sep 2009, Patrick McHardy wrote:

> That explains it. The bnx2 driver uses multiple TX queues, but
> tc_dump_qdisc() only dumps the statistics from queue number 0.

There are no stats in other queues either... This is the result after
sending 10000 or so packets. Maybe I am not catching all the qdiscs?

(this is the result of a pretty raw patch to dump all qdiscs)

#cat /proc/net/qdisc_stats
Type Device State Bytes Packets Qlen Backlog Drops Requeues Overlimits
TX root <NULL> 0 0 0 0 0 0 0 0
RX root <NULL> 0 0 0 0 0 0 0 0
TX root  eth0 0 24830 155 0 0 0 0 0
RX root <NULL> 0 0 0 0 0 0 0 0
TX root <NULL> 0 0 0 0 0 0 0 0
RX root <NULL> 0 0 0 0 0 0 0 0
TX root <NULL> 0 0 0 0 0 0 0 0
RX root <NULL> 0 0 0 0 0 0 0 0
TX root <NULL> 0 0 0 0 0 0 0 0
RX root <NULL> 0 0 0 0 0 0 0 0

---
 net/sched/sch_api.c |   64 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

Index: linux-2.6/net/sched/sch_api.c
===================================================================
--- linux-2.6.orig/net/sched/sch_api.c	2009-08-31 21:19:04.000000000 +0000
+++ linux-2.6/net/sched/sch_api.c	2009-09-01 14:30:40.000000000 +0000
@@ -1699,6 +1699,69 @@ static const struct file_operations psch
 	.llseek = seq_lseek,
 	.release = single_release,
 };
+
+static void dump_qdisc(struct seq_file *seq, struct Qdisc *q, char *inout, char *text)
+{
+	seq_printf(seq, "%2s %2s %5s %lx %lld %d %d %d %d %d %d\n",
+		inout, text, q->dev_queue->dev->name, q->state,
+		q->bstats.bytes, q->bstats.packets,
+		q->qstats.qlen, q->qstats.backlog, q->qstats.drops,
+		q->qstats.requeues, q->qstats.overlimits);
+}
+
+static void dump_qdisc_root(struct seq_file *seq, struct Qdisc *root, char *inout)
+{
+	struct Qdisc *q;
+	int n = 0;
+
+	if (!root)
+		return;
+
+	dump_qdisc(seq, root, inout, "root");
+
+	list_for_each_entry(q, &root->list, list) {
+		char buffer[10];
+
+		sprintf(buffer,"%d", ++n);
+		dump_qdisc(seq, q, inout, buffer);
+	}
+}
+
+
+static int qdisc_show(struct seq_file *seq, void *v)
+{
+	struct net_device *dev;
+
+	seq_printf(seq, "Type Device State Bytes Packets "
+			"Qlen Backlog Drops Requeues Overlimits\n");
+
+	read_lock(&dev_base_lock);
+
+	for_each_netdev(&init_net, dev) {
+		struct netdev_queue *dev_queue;
+
+		dev_queue = netdev_get_tx_queue(dev, 0);
+		dump_qdisc_root(seq, dev_queue->qdisc_sleeping, "TX");
+		dev_queue = &dev->rx_queue;
+		dump_qdisc_root(seq, dev_queue->qdisc_sleeping, "RX");
+	}
+
+	read_unlock(&dev_base_lock);
+	return 0;
+}
+
+static int qdisc_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, qdisc_show, PDE(inode)->data);
+}
+
+static const struct file_operations qdisc_fops = {
+	.owner = THIS_MODULE,
+	.open = qdisc_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
 #endif

 static int __init pktsched_init(void)
@@ -1706,6 +1769,7 @@ static int __init pktsched_init(void)
 	register_qdisc(&pfifo_qdisc_ops);
 	register_qdisc(&bfifo_qdisc_ops);
 	proc_net_fops_create(&init_net, "psched", 0, &psched_fops);
+	proc_net_fops_create(&init_net, "qdisc_stats", 0, &qdisc_fops);

 	rtnl_register(PF_UNSPEC, RTM_NEWQDISC, tc_modify_qdisc, NULL);
 	rtnl_register(PF_UNSPEC, RTM_DELQDISC, tc_get_qdisc, NULL);

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 15:28               ` Eric Dumazet
@ 2009-09-01 19:35                 ` Christoph Lameter
  2009-09-01 15:43                   ` Eric Dumazet
  0 siblings, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 19:35 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev

On Tue, 1 Sep 2009, Eric Dumazet wrote:

> You should see that in /proc/interrupts, if I correctly understand bnx2.c

Hmmm I have 8 interrupts:

  62:        158          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-0
  63:         84          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-1
  64:        412          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-2
  65:         25          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-3
  66:      49718          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-4
  67:         65          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-5
  68:        686          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-6
  69:       2582          0          0          0          0          0
0          0          0          0          0          0          0
0          0          0  IR-PCI-MSI-edge      eth0-7

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 15:58                     ` Eric Dumazet
@ 2009-09-01 20:13                       ` Christoph Lameter
  2009-09-01 21:55                       ` Christoph Lameter
  1 sibling, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 20:13 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev

On Tue, 1 Sep 2009, Eric Dumazet wrote:

> For your multicast test anyway, only one queue should be used (one flow)

Right.

I finally get some numbers with the qdisc_stats patch:

clameter@rd-strategy3-deb64:~$ cat /proc/net/qdisc_stats
Type     Device St  Bytes    Packts Qlen Bklg Drops  Requeu Overlimits
TXS root <NULL>   0        0      0    0    0      0      0      0
TX root <NULL>   0        0      0    0    0      0      0      0
RXS root <NULL>   0        0      0    0    0      0      0      0
RX root <NULL>   0        0      0    0    0      0      0      0
TXS root   eth0   0     2778     35    0    0      0      0      0
TX root   eth0   0     2778     35    0    0      0      0      0
TXS root   eth0   0     1622     18    0    0      0      0      0
TX root   eth0   0     1622     18    0    0      0      0      0
TXS root   eth0   0     2618     22    0    0      0      0      0
TX root   eth0   0     2618     22    0    0      0      0      0
TXS root   eth0   0     9792     65    0    0      0      0      0
TX root   eth0   0     9792     65    0    0      0      0      0
TXS root   eth0   0     9758     68    0    0      0      0      0
TX root   eth0   0     9758     68    0    0      0      0      0
TXS root   eth0   0     1413     18    0    0      0      0      0
TX root   eth0   0     1413     18    0    0      0      0      0
TXS root   eth0   0      557      8    0    0      0      0      0
TX root   eth0   0      557      8    0    0      0      0      0
TXS root   eth0   0     1220     11    0    0      0      0      0
TX root   eth0   0     1220     11    0    0      0      0      0
RXS root <NULL>   0        0      0    0    0      0      0      0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 21:55                       ` Christoph Lameter
@ 2009-09-01 20:24                         ` Jarek Poplawski
  2009-09-02  1:36                           ` Christoph Lameter
  0 siblings, 1 reply; 21+ messages in thread
From: Jarek Poplawski @ 2009-09-01 20:24 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: Eric Dumazet, Patrick McHardy, Mark Smith, netdev

On Tue, Sep 01, 2009 at 05:55:44PM -0400, Christoph Lameter wrote:
> 
> Ok i got some meaningful statistics now. Why is the qlen zero for all
> devices?

Looks like it's updated with q->q.qlen before dumps only. Nice work!
Btw, isn't there something with your localhost's time?

Original-Received: from ...
	...
	for <netdev@vger.kernel.org>; Tue,  1 Sep 2009 13:58:12 -0400 (EDT)
Original-Received: from cl (helo=localhost)
	...
	id 1MibKK-0007nd-Ib; Tue, 01 Sep 2009 17:55:44 -0400

Jarek P.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 15:58                     ` Eric Dumazet
  2009-09-01 20:13                       ` Christoph Lameter
@ 2009-09-01 21:55                       ` Christoph Lameter
  2009-09-01 20:24                         ` Jarek Poplawski
  1 sibling, 1 reply; 21+ messages in thread
From: Christoph Lameter @ 2009-09-01 21:55 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Patrick McHardy, Mark Smith, Jarek Poplawski, netdev


Ok i got some meaningful statistics now. Why is the qlen zero for all
devices?

$ cat /proc/net/qdisc_stats
Type     Device  St    Bytes Packts Qlen Bklg  Drops Requeu Overlimit
TX0 root     lo   0        0      0    0    0      0      0      0
 RX root     lo   0        0      0    0    0      0      0      0
TX0 root   eth0   0    12463     91    0    0      0      0      0
TX1 root   eth0   0     2954     39    0    0      0      0      0
TX2 root   eth0   0     2132     23    0    0      0      0      0
TX3 root   eth0   0    29293    210    0    0      0      0      0
TX4 root   eth0   0     2805     31    0    0      0      0      0
TX5 root   eth0   0 1286862317 3762765    0    0 643253  30886      0
TX6 root   eth0   0     1310     17    0    0      0      0      0
TX7 root   eth0   0     2860     31    0    0      0      0      0

---
 net/sched/sch_api.c |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

Index: linux-2.6/net/sched/sch_api.c
===================================================================
--- linux-2.6.orig/net/sched/sch_api.c	2009-09-01 12:27:24.000000000 -0500
+++ linux-2.6/net/sched/sch_api.c	2009-09-01 12:40:30.000000000 -0500
@@ -1699,6 +1699,77 @@ static const struct file_operations psch
 	.llseek = seq_lseek,
 	.release = single_release,
 };
+
+static void dump_qdisc(struct seq_file *seq, struct net_device *dev,
+				struct Qdisc *q, char *inout, char *text)
+{
+	seq_printf(seq, "%3s %2s %6s %3lx %8lld %6d %4d %4d %6d %6d %6d\n",
+		inout, text, dev->name, q->state,
+		q->bstats.bytes, q->bstats.packets,
+		q->qstats.qlen, q->qstats.backlog, q->qstats.drops,
+		q->qstats.requeues, q->qstats.overlimits);
+}
+
+static void dump_qdisc_root(struct seq_file *seq, struct net_device *dev,
+					 struct Qdisc *root, char *inout)
+{
+	struct Qdisc *q;
+	int n = 0;
+
+	if (!root)
+		return;
+
+	dump_qdisc(seq, dev, root, inout, "root");
+
+	list_for_each_entry(q, &root->list, list) {
+		char buffer[10];
+
+		sprintf(buffer,"Q%d", ++n);
+		dump_qdisc(seq, dev, q, inout, buffer);
+	}
+}
+
+
+static int qdisc_show(struct seq_file *seq, void *v)
+{
+	struct net_device *dev;
+
+	seq_printf(seq, "Type     Device  St    Bytes Packts "
+			"Qlen Bklg  Drops Requeu Overlimit\n");
+
+	read_lock(&dev_base_lock);
+
+	for_each_netdev(&init_net, dev) {
+		struct netdev_queue *dev_queue;
+		int i;
+
+		for (i = 0; i < dev->real_num_tx_queues; i++) {
+			char buffer[10];
+
+			dev_queue = netdev_get_tx_queue(dev, i);
+			sprintf(buffer, "TX%d", i);
+			dump_qdisc_root(seq, dev, dev_queue->qdisc_sleeping, buffer);
+		}
+		dev_queue = &dev->rx_queue;
+		dump_qdisc_root(seq, dev, dev_queue->qdisc_sleeping, "RX");
+	}
+
+	read_unlock(&dev_base_lock);
+	return 0;
+}
+
+static int qdisc_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, qdisc_show, PDE(inode)->data);
+}
+
+static const struct file_operations qdisc_fops = {
+	.owner = THIS_MODULE,
+	.open = qdisc_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
 #endif

 static int __init pktsched_init(void)
@@ -1706,6 +1777,7 @@ static int __init pktsched_init(void)
 	register_qdisc(&pfifo_qdisc_ops);
 	register_qdisc(&bfifo_qdisc_ops);
 	proc_net_fops_create(&init_net, "psched", 0, &psched_fops);
+	proc_net_fops_create(&init_net, "qdisc_stats", 0, &qdisc_fops);

 	rtnl_register(PF_UNSPEC, RTM_NEWQDISC, tc_modify_qdisc, NULL);
 	rtnl_register(PF_UNSPEC, RTM_DELQDISC, tc_get_qdisc, NULL);

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: UDP is bypassing qdisc statistics ....
  2009-09-01 20:24                         ` Jarek Poplawski
@ 2009-09-02  1:36                           ` Christoph Lameter
  0 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2009-09-02  1:36 UTC (permalink / raw)
  To: Jarek Poplawski; +Cc: Eric Dumazet, Patrick McHardy, Mark Smith, netdev

On Tue, 1 Sep 2009, Jarek Poplawski wrote:

> Btw, isn't there something with your localhost's time?

Yup. I have virtual hosting and the provider screwed up time. I can do
nothing about it.

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2009-09-01 21:37 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-31 21:46 UDP is bypassing qdisc statistics Christoph Lameter
2009-08-31 19:54 ` Eric Dumazet
2009-08-31 20:58   ` Mark Smith
2009-09-01  6:37     ` Jarek Poplawski
2009-09-01  7:00       ` Eric Dumazet
2009-09-01  9:37         ` Mark Smith
2009-09-01 18:03       ` Christoph Lameter
2009-09-01 14:20         ` Patrick McHardy
2009-09-01 14:58           ` Eric Dumazet
2009-09-01 19:05             ` Christoph Lameter
2009-09-01 15:28               ` Eric Dumazet
2009-09-01 19:35                 ` Christoph Lameter
2009-09-01 15:43                   ` Eric Dumazet
2009-09-01 15:58                     ` Eric Dumazet
2009-09-01 20:13                       ` Christoph Lameter
2009-09-01 21:55                       ` Christoph Lameter
2009-09-01 20:24                         ` Jarek Poplawski
2009-09-02  1:36                           ` Christoph Lameter
2009-09-01 18:29           ` Christoph Lameter
2009-09-01 19:30           ` Christoph Lameter
2009-09-01 15:34             ` Eric Dumazet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).