From: Albert Chin <linux-netdev@mlists.thewrittenword.com>
To: netdev@vger.kernel.org
Subject: Re: Problems with dropped packets on bonded interface for 3.x kernels
Date: Mon, 21 Nov 2011 01:44:54 -0600 [thread overview]
Message-ID: <20111121074453.GA7596@china> (raw)
In-Reply-To: <1321857123.17419.2.camel@edumazet-laptop>
On Mon, Nov 21, 2011 at 07:32:03AM +0100, Eric Dumazet wrote:
> Le dimanche 20 novembre 2011 à 23:16 -0600, Albert Chin a écrit :
> > I'm running Ubuntu 11.10 on an Intel SR2625URLXR system with an Intel
> > S5520UR motherboard and an internal Intel E1G44HT (I340-T4) Quad Port
> > Server Adapter. I am seeing dropped packets on a bonded interface,
> > comprised of two GigE ports on the Intel E1G44HT Quad Port Server
> > Adapter. The following kernels exhibit this problem:
> > 3.0.0-12-server, 3.0.0-13-server, 3.1.0-2-server, 3.2.0-rc2
> > Installing Fedora 16 with a 3.1.1-1.fc16.x86_64 also showed dropped
> > packets.
> >
> > I also tried RHEL6 with a 2.6.32-131.17.1.el6.x86_64 kernel and didn't
> > see any dropped packets. Testing an older 2.6.32-28.55-generic Ubuntu
> > kernel also didn't show any dropped packets.
> >
> > So, with 2.6, I don't see dropped packets, but everything including
> > 3.0 and after show dropped packets.
> >
> > # ifconfig bond0
> > bond0 Link encap:Ethernet HWaddr 00:1b:21:d3:f6:0a
> > inet6 addr: fe80::21b:21ff:fed3:f60a/64 Scope:Link
> > UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
> > RX packets:225 errors:0 dropped:186 overruns:0 frame:0
> > TX packets:231 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:0
> > RX bytes:25450 (25.4 KB) TX bytes:28368 (28.3 KB)
> >
> > [[ snip snip ]]
>
> Old kernels were dropping some packets (unknown protocols...) without
> counting them.
>
> So following patch was added in 2.6.37 :
>
> You could use tcdpump to identify what are these dropped packets :)
So only "unknown" protocols are dropped? I just ran tcpdump for 96
packets and inspected the output. The only packets received are LACP,
ARP, STP (Spanning Tree Protocol), DTP (Dynamic Trunking Protocol).
How are these "unknown"?
> commit caf586e5f23cebb2a68cbaf288d59dbbf2d74052
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Sep 30 21:06:55 2010 +0000
>
> net: add a core netdev->rx_dropped counter
>
> In various situations, a device provides a packet to our stack and we
> drop it before it enters protocol stack :
> - softnet backlog full (accounted in /proc/net/softnet_stat)
> - bad vlan tag (not accounted)
> - unknown/unregistered protocol (not accounted)
>
> We can handle a per-device counter of such dropped frames at core level,
> and automatically adds it to the device provided stats (rx_dropped), so
> that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
>
> This is a generalization of commit 8990f468a (net: rx_dropped
> accounting), thus reverting it.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
--
albert chin (china@thewrittenword.com)
next prev parent reply other threads:[~2011-11-21 7:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 5:16 Problems with dropped packets on bonded interface for 3.x kernels Albert Chin
2011-11-21 6:32 ` Eric Dumazet
2011-11-21 7:44 ` Albert Chin [this message]
2011-11-21 8:02 ` Eric Dumazet
2011-11-21 8:08 ` Albert Chin
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=20111121074453.GA7596@china \
--to=linux-netdev@mlists.thewrittenword.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.