From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Sridhar Samudrala <sri@us.ibm.com>,
David Stevens <dlstevens@us.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, niv@linux.vnet.ibm.com
Subject: Re: UDP multicast packet loss not reported if TX ring overrun?
Date: Fri, 28 Aug 2009 17:07:32 +0200 [thread overview]
Message-ID: <4A97F2B4.7030900@gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0908280948320.3747@gentwo.org>
Christoph Lameter a écrit :
> The qdisc drop counter is incremented in pfifo_fast. So Sridhar's patch is
> not necessary.
>
> Seems though that the qdisc drop count does not flow into the tx_dropped
> counter for the interface. Incrementing the tx_dropped count in the
> netdev_queue associated with the outbound qdisc also had no effect (see
> the following patch).
>
> Plus I only see one queue for eth0 with "tc -s qdisc show". I think that
> what I see there is the queue for receiving packets. tc uses this ugly
> netlink interface. Could be a bug in there or in the netlink interface?
> Or is there some other trick to display queue statistics for outgoing
> packets?
"tc -s qdisc show" only displays queue info for tx packets.
>
> WTH is going on here? Noone was ever interested in making outbound packet
> loss account right?
>
I have no idea of what your problem can be Christoph.
Here, on unpatched git linux-2.6 kernel, default qdisc, and an udp tx flood I get :
# tc -s -d qdisc show dev eth3
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 18025794122 bytes 17299241 pkt (dropped 264892, overlimits 0 requeues 68282)
rate 0bit 0pps backlog 20840b 20p requeues 68282
>
> Index: linux-2.6.31-rc7/include/net/sch_generic.h
> ===================================================================
> --- linux-2.6.31-rc7.orig/include/net/sch_generic.h 2009-08-27
> 21:20:03.000000000 +0000
> +++ linux-2.6.31-rc7/include/net/sch_generic.h 2009-08-27
> 21:26:33.000000000 +0000
> @@ -509,6 +509,9 @@ static inline int qdisc_drop(struct sk_b
> kfree_skb(skb);
> sch->qstats.drops++;
>
> + /* device queue statistics */
> + sch->dev_queue->tx_dropped++;
> +
> return NET_XMIT_DROP;
> }
locking problem here, tx_dropped can be changed by another cpu.
As David Stevens pointed out, device was not ever called at all when your packet(s) was/were lost.
Why should we account a non existent drop at device level ?
When a process wants a new memory page and hits its own limit, do you want to increment a system global
counter saying 'memory allocation failed' ?
So in my case :
$ ifconfig eth3
eth3 Link encap:Ethernet HWaddr 00:1E:0B:92:78:51
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1188 errors:0 dropped:0 overruns:0 frame:0
TX packets:63774907 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:633918 (619.0 KiB) TX bytes:105287564 (100.4 MiB)
Interrupt:16
And yes, dropped:0 is OK here, since packets where dropped at qdisc layer.
Only change you want is eventually to account for the UDP drop (SndbufErrors).
next prev parent reply other threads:[~2009-08-28 15:08 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 20:01 UDP multicast packet loss not reported if TX ring overrun? Christoph Lameter
2009-08-17 20:40 ` Nivedita Singhvi
2009-08-17 20:46 ` Christoph Lameter
2009-08-17 21:50 ` Sridhar Samudrala
2009-08-17 22:13 ` Christoph Lameter
2009-08-17 22:43 ` Sridhar Samudrala
2009-08-17 22:52 ` Christoph Lameter
2009-08-17 22:57 ` Christoph Lameter
2009-08-18 0:12 ` Sridhar Samudrala
2009-08-18 0:25 ` Christoph Lameter
2009-08-24 17:40 ` Christoph Lameter
2009-08-24 22:02 ` Eric Dumazet
2009-08-24 22:36 ` Sridhar Samudrala
2009-08-25 13:48 ` Christoph Lameter
2009-08-25 19:03 ` David Stevens
2009-08-25 19:08 ` David Miller
2009-08-25 19:15 ` Christoph Lameter
2009-08-25 19:56 ` Joe Perches
2009-08-25 22:35 ` Sridhar Samudrala
2009-08-26 14:08 ` Christoph Lameter
2009-08-26 14:22 ` Eric Dumazet
2009-08-26 15:27 ` Christoph Lameter
2009-08-26 16:29 ` Christoph Lameter
2009-08-26 17:50 ` Sridhar Samudrala
2009-08-26 19:09 ` Christoph Lameter
2009-08-26 22:11 ` Sridhar Samudrala
2009-08-27 15:40 ` Christoph Lameter
2009-08-27 20:23 ` Christoph Lameter
2009-08-28 13:53 ` Christoph Lameter
2009-08-28 15:07 ` Eric Dumazet [this message]
2009-08-28 16:15 ` Christoph Lameter
2009-08-28 17:26 ` [PATCH net-next-2.6] ip: Report qdisc packet drops Eric Dumazet
2009-08-29 6:38 ` David Miller
2009-08-31 12:09 ` Eric Dumazet
2009-09-02 1:41 ` David Miller
2009-09-02 14:43 ` Eric Dumazet
2009-09-02 16:11 ` Sridhar Samudrala
2009-09-02 16:20 ` Eric Dumazet
2009-09-02 19:37 ` Christoph Lameter
2009-09-02 16:05 ` Eric Dumazet
2009-09-02 22:26 ` Eric Dumazet
2009-09-03 1:05 ` David Miller
2009-09-03 17:57 ` Christoph Lameter
2009-09-03 14:12 ` Eric Dumazet
2009-09-03 18:35 ` Christoph Lameter
2009-09-02 18:22 ` Christoph Lameter
2009-09-03 1:09 ` David Miller
2009-08-28 19:26 ` UDP multicast packet loss not reported if TX ring overrun? David Miller
2009-08-28 20:00 ` Christoph Lameter
2009-08-28 20:04 ` David Miller
2009-08-28 19:24 ` David Miller
2009-08-28 19:53 ` Christoph Lameter
2009-08-28 20:03 ` David Miller
2009-08-28 20:09 ` Christoph Lameter
2009-08-30 0:21 ` Mark Smith
2009-08-25 13:46 ` Christoph Lameter
2009-08-25 13:48 ` Eric Dumazet
2009-08-25 14:00 ` Christoph Lameter
2009-08-25 15:32 ` Eric Dumazet
2009-08-25 15:35 ` Christoph Lameter
2009-08-25 15:58 ` Eric Dumazet
2009-08-25 16:11 ` Christoph Lameter
2009-08-25 16:27 ` Eric Dumazet
2009-08-25 16:36 ` Christoph Lameter
2009-08-25 16:48 ` Eric Dumazet
2009-08-25 17:01 ` Christoph Lameter
2009-08-25 17:08 ` Eric Dumazet
2009-08-25 17:44 ` Christoph Lameter
2009-08-25 17:53 ` Christoph Lameter
2009-08-25 18:38 ` Sridhar Samudrala
2009-08-24 23:14 ` Eric Dumazet
2009-08-25 6:46 ` Eric Dumazet
2009-08-25 13:45 ` Christoph Lameter
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=4A97F2B4.7030900@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dlstevens@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=niv@linux.vnet.ibm.com \
--cc=sri@us.ibm.com \
/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 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).