On 29 November 2012 21:37, Claudio Jeker <[email protected]> wrote: > On Thu, Nov 29, 2012 at 09:21:49PM +0100, Mark Kettenis wrote: >> > Date: Thu, 29 Nov 2012 20:49:00 +0100 >> > From: Claudio Jeker <[email protected]> >> > >> > On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: >> > > On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: >> > > > hi, >> > > > >> > > > drivers ex age alc ale jme se vic vte xe upl and octeon/cmac >> > > > make use of the if_iqdrops counter that is not shown by any of our >> > > > tools (like netstat). looks like most of its usage comes from >> > > > freebsd where they show it in the "netstat -di" output in a new >> > > > column. do we want to do that or just convert them to if_ierrors >> > > > since 90% of our drivers do only if_ierrors. there's also doesn't >> > > > seem to be any rule when to use if_iqdrops (well, since in most >> > > > drivers there's no input queueing -- check out upl(4) :) >> > > > >> > > > the diff below changes all the drivers in our tree to use >> > > > if_ierrors instead of if_iqdrops. i've decided to leave >> > > > octeon/cmac driver as is because if_iqdrops is used for >> > > > debugging purposes there. >> > > > >> > > > ack? nack? meh? >> > > >> > > Seems like a good idea to me to not lose those errors. I have >> > > no great desire for a new column in netstat, but no great >> > > antagonism to one either. >> > > >> > >> > I guess the idea is to show which interfaces are overloading the input >> > queues. At least that is my interpretation of if_iqdrops (input queue >> > drops). In a away it makes sense but I'm not to attached to it. I would >> > prefer we would actually print out the output queue drops on the interface >> > queue. >> >> Actually, in the network (hardware) drivers this is used to flag the >> "oh shit, I cannot allocate a new mbuf, let's drop the packet I just >> received such that I can keep my ring filled" conditions. It is >> somewhat useful to be able to distinguish this condition from packets >> that were dropped by the hardware because they were not received >> correctly. > > True, it would also help in mclgeti drivers to distinguish between packets > that got dropped because of errors or because of mclgeti. >
but we don't increment ierrors when mclgeti fails.
