lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ