From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Sridhar Samudrala <sri@us.ibm.com>,
Nivedita Singhvi <niv@us.ibm.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: UDP multicast packet loss not reported if TX ring overrun?
Date: Tue, 25 Aug 2009 00:02:23 +0200 [thread overview]
Message-ID: <4A930DEF.5000008@gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0908241334230.30487@gentwo.org>
Christoph Lameter a écrit :
> On Mon, 17 Aug 2009, Sridhar Samudrala wrote:
>
>> So it is possible that there is some other place in the stack where the packets
>> are gettting dropped but not counted.
>
> Such a deed occurs in ip_push_pending_frames():
>
> /* Netfilter gets whole the not fragmented skb. */
> err = ip_local_out(skb);
> if (err) {
> if (err > 0)
> err = inet->recverr ? net_xmit_errno(err) : 0;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> if (err)
> goto error;
> }
>
> out:
> ip_cork_release(inet);
> return err;
>
> error:
> IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
> goto out;
>
>
> So if ip_local_out returns NET_XMIT_DROP then its simply going to be
> replaced by 0. Then we check err again and there is no error!!!!
>
> The statistics are only generated if IP_RECVERR is set.
>
> Could we move the increment of IPSTATS_MIB_OUTDISCARDS up so that it
> is incremented regardless of the setting of IP_RECVERR?
>
> F.e?
>
>
> Subject: Report TX drops
>
> Incrementing of TX drop counters currently does not work if errors from the
> network stack are suppressed (IP_RECVERR off). Increment the statistics
> independently of the setting of IP_RECVERR.
>
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
>
> ---
> net/ipv4/ip_output.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> Index: linux-2.6/net/ipv4/ip_output.c
> ===================================================================
> --- linux-2.6.orig/net/ipv4/ip_output.c 2009-08-24 17:04:27.000000000 +0000
> +++ linux-2.6/net/ipv4/ip_output.c 2009-08-24 17:32:05.000000000 +0000
> @@ -1300,20 +1300,21 @@ int ip_push_pending_frames(struct sock *
>
> /* Netfilter gets whole the not fragmented skb. */
> err = ip_local_out(skb);
> - if (err) {
> - if (err > 0)
> - err = inet->recverr ? net_xmit_errno(err) : 0;
> - if (err)
> - goto error;
> + if (err > 0) {
> + /* The packet was dropped by the network subsystem */
> + IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
> +
> + /*
> + * Errors are not passed on if the socket
> + * does not process errors (see IP_RECVERR).
> + * net_xmit_errno filters NET_XMIT_CN.
> + */
> + err = inet->recverr ? net_xmit_errno(err) : 0;
> }
>
> out:
> ip_cork_release(inet);
> return err;
> -
> -error:
> - IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
> - goto out;
> }
>
> /*
>
>
>
>
NET_XMIT_CN strikes again :)
Well, if ip_local_out() returns a negative error (say -EPERM for example),
your patch disables OUTDISCARDS increments.
Maybe a simpler patch like this one ?
[PATCH] net: correctly updates OUTDISCARDS in ip_push_pending_frames()
ip_push_pending_frames() can fail to send a frame because of a congestioned
device. In this case, we increment SNMP OUTDISCARDS only if user set
IP_RECVERR, which is not RFC conformant.
Only case where we should not update OUTDISCARDS is when
ip_local_output() return value is NET_XMIT_CN (meaning
skb was xmitted but future frames might be dropped)
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7d08210..27a5b79 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1301,19 +1301,15 @@ int ip_push_pending_frames(struct sock *sk)
/* Netfilter gets whole the not fragmented skb. */
err = ip_local_out(skb);
if (err) {
+ if (err != NET_XMIT_CN)
+ IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
if (err > 0)
err = inet->recverr ? net_xmit_errno(err) : 0;
- if (err)
- goto error;
}
out:
ip_cork_release(inet);
return err;
-
-error:
- IP_INC_STATS(net, IPSTATS_MIB_OUTDISCARDS);
- goto out;
}
/*
next prev parent reply other threads:[~2009-08-24 22:02 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 [this message]
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
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=4A930DEF.5000008@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=niv@us.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 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.