* 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 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
* 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 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 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 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 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 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 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 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 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 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 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
* 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: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 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
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).