All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: netdev@vger.kernel.org, davem@linux-foundation.org
Subject: Re: UDP is bypassing qdisc statistics ....
Date: Mon, 31 Aug 2009 21:54:49 +0200	[thread overview]
Message-ID: <4A9C2A89.9060002@gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0908311632170.1507@V090114053VZO-1>

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...

  reply	other threads:[~2009-08-31 19:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-31 21:46 UDP is bypassing qdisc statistics Christoph Lameter
2009-08-31 19:54 ` Eric Dumazet [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A9C2A89.9060002@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=cl@linux-foundation.org \
    --cc=davem@linux-foundation.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.