On 02/12/2014 05:44 AM, Mike Belopuhov wrote:
On 11 February 2014 20:05, Brad Smith <b...@comstyle.com> wrote:
On Tue, Feb 11, 2014 at 07:43:51PM +0100, Mark Kettenis wrote:
Date: Tue, 11 Feb 2014 13:30:47 -0500
From: Brad Smith <b...@comstyle.com>
Index: arch/socppc/dev/if_tsec.c
===================================================================
RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 if_tsec.c
--- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 -0000 1.29
+++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 -0000
@@ -779,7 +779,6 @@ tsec_errintr(void *arg)
*/
tsec_rx_proc(sc);
tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT);
- ifp->if_ierrors++;
}
return (1);
This one doesn't seem right. This is the only place where the driver
actually increases if_ierrors.
Being the only place input errors are incremented is irrelevant.
Its being incremented because the particular "error" is a FIFO overrun.
I also still fundamentally disagree with the direction. I you guys
really want to make a distinction between packets dropped because
we're out of descriptors and packets that were not correctly received
for other reasons, add a counter for that first and then change the
drivers.
I don't necessarily disagree with what you have said. I think we should
have some additional counters to deal with some of the counters we
are lumping into error counters.
Since we can't seem to come to any consensus about how to deal with
this I'm going to revert the bge(4) commit in question.
no way. counting drops caused by the mclgeti should not be accounted
as input errors. it makes it hard to debug things.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Locating where and why packets are dropped is essential to debugging network
overload problems. A per-interface "packets dropped because of lack of
resources"
would make that process easier. There used to be several places in packet
reception where packets were dropped with no record. I inserted counters
to get at least a global count. It's conceptually very ugly to silently fail
in a vital part of the network stack. It's definitely a frustrating
inconvenience.
Geoff Steckel
