| Message ID | 4A9BBD8E.2010303@gmail.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Mon, 31 Aug 2009 14:09:50 +0200 > Re-reading again this stuff, I realized ip6_push_pending_frames() > was not updating IPSTATS_MIB_OUTDISCARDS, even if IP_RECVERR was set. > > May I suggest following path : > > 1) Correct ip6_push_pending_frames() to properly > account for dropped-by-qdisc frames when IP_RECVERR is set Your patch is applied to net-next-2.6, thanks! > 2) Submit a patch to account for qdisc-dropped frames in SNMP counters > but still return a OK to user application, to not break them ? Sounds good. I think if you sample random UDP applications, you will find that such errors will upset them terribly, make them log tons of crap to /var/log/messages et al., and consume tons of CPU. And in such cases silent ignoring of drops is entirely appropriate and optimal, which supports our current behavior. If we are to make such applications "more sophisticated" such converted apps can be indicated simply their use of IP_RECVERR. If you want to be notified of all asynchronous errors we can detect, you use this, end of story. It is the only way to handle this situation without breaking the world. As usual, Alexey Kuznetsov's analysis of this situation is timeless, accurate, and wise. And he understood all of this 10+ years ago. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 1 Sep 2009, David Miller wrote: > > 2) Submit a patch to account for qdisc-dropped frames in SNMP counters > > but still return a OK to user application, to not break them ? > > Sounds good. Great. That was my initial suggestion and it would ensure that no apps break. > If we are to make such applications "more sophisticated" such > converted apps can be indicated simply their use of IP_RECVERR. There may be a minor issue here in that IP_RECVERR sometimes sends error packets that have to be intercepted using special code. Or can those be simply ignored? If so then I will ask UDP app vendors to use IP_RECVERR. > As usual, Alexey Kuznetsov's analysis of this situation is timeless, > accurate, and wise. And he understood all of this 10+ years ago. His code was just slightly buggy .... ;-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Christoph Lameter <cl@linux-foundation.org> Date: Wed, 2 Sep 2009 13:22:25 -0500 (CDT) > There may be a minor issue here in that IP_RECVERR sometimes sends error > packets that have to be intercepted using special code. Or can those be > simply ignored? If so then I will ask UDP app vendors to use IP_RECVERR. If you don't set MSG_ERRQUEUE, no special error reports will be given to the application. And this only matters for recvmsg() handling. On send, the only behavior difference is this error code reporting (and before Eric's patch, SNMP statistics handling). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 6ad5aad..a931229 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1520,6 +1520,7 @@ out: ip6_cork_release(inet, np); return err; error: + IP6_INC_STATS(net, rt->rt6i_idev, IPSTATS_MIB_OUTDISCARDS); goto out; }