[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B735E@saturn3.aculab.com>
Date: Thu, 26 Sep 2013 10:32:24 +0100
From: "David Laight" <David.Laight@...LAB.COM>
To: "David Miller" <davem@...emloft.net>
Cc: <netdev@...r.kernel.org>
Subject: RE: rx_dropped count for USB ethernet interfaces
> From: David Miller [mailto:davem@...emloft.net]
> > Edited slightly...
> > We are seeing the 'rx_dropped' count increasing on ethernet interfaces.
> >
> > Now I thought that rx_dropped was a count of the number of packets
> > that the MAC driver/hardware discarded - typically because the rx
> > ring had no buffers. This could include packets dropped in the
> > receive stack due to other memory limits.
> >
> > However it looks as though Linux is also counting rx_dropped if
> > the packet can't be delivered to a protocol.
>
> This is expected and correct behavior.
It isn't exactly useful behaviour though.
Two different things are being counted together.
Packets dropped by the hardware (or by ENOMEM errors) are packets
that haven't been delivered to the protocol stack - so cause
some kind of protocol recovery actions.
If any of these are happening there is usually something wrong
with the system/network.
Packets for which there is no protocol are largely boring.
Especially if they are multicast packets.
A compromise might be to only count packets that are directed
to the interface's MAC address.
In this case there is at least some expectation that the system
should process the packet.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists