All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Poirier <benjamin.poirier@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ben Greear <greearb@candelatech.com>, netdev <netdev@vger.kernel.org>
Subject: Re: More details on why received UDP packets are treated as errors?
Date: Tue, 30 Jul 2013 16:38:10 -0400	[thread overview]
Message-ID: <20130730203810.GC24932@d2.synalogic.ca> (raw)
In-Reply-To: <1375129292.10515.21.camel@edumazet-glaptop>

On 2013/07/29 13:21, Eric Dumazet wrote:
> On Mon, 2013-07-29 at 11:21 -0700, Ben Greear wrote:
> > We have a test case on 3.9.9+ (local patches applied) where sending from
> > VETH interface, through peer VETH bridged (with our own emulator bridge module)
> > to physical interface, which is then looped to another physical interface (B).
> > The VETH and the wired B interface are sending UDP traffic to each other.
> > Routing rules should be configured such that this all works appropriately.
> > 
> > Replacing our bridging module with a user-space bridge has same behaviour.
> > 
> > This setup works on the 3.7.y kernel, but we only get one-way traffic
> > (B to VETH) on 3.9.9+.
> > 
> > I sniffed the B port, and traffic appears to be sent and received
> > properly (ie, no checksum errors, etc).  But, our user-space app
> > shows no received UDP frames on B, and netstat -s gives the
> > output below.
> > 
> > Is there any way to get more details about what these 'packet receive errors'
> > are caused by using normal-ish tools?
> 
> You could try dropwatch for this kind of obscure drops
> 
> https://fedorahosted.org/dropwatch/

If the drop happens in __udp_queue_rcv_skb() you can also get some info from
the udp_fail_queue_rcv_skb tracepoint. See "296f7ea udp: add tracepoints for
queueing skb to rcvbuf (v3.1-rc1)".

  reply	other threads:[~2013-07-30 20:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29 18:21 More details on why received UDP packets are treated as errors? Ben Greear
2013-07-29 20:21 ` Eric Dumazet
2013-07-30 20:38   ` Benjamin Poirier [this message]
2013-08-08  0:10   ` Ben Greear

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=20130730203810.GC24932@d2.synalogic.ca \
    --to=benjamin.poirier@gmail.com \
    --cc=eric.dumazet@gmail.com \
    --cc=greearb@candelatech.com \
    --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.