> From: Mike Belopuhov <m...@belopuhov.com> > Date: Thu, 29 Nov 2012 21:41:28 +0100 > > On 29 November 2012 21:37, Claudio Jeker <cje...@diehard.n-r-g.com> 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 <cje...@diehard.n-r-g.com> > >> > > >> > 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.
Not really. > but we don't increment ierrors when mclgeti fails. Some don't, some do. I believe that doing so would be wrong. But since we won't refill the ring, the hardware will start dropping packets. Most hardware will set some sort of error bit in this case, and the driver will probably increase if_ierrors in response. Perhaps drivers that can distinguish between packets being dropped because there is no space on the rx ring and packets being dropped because they are corrupt should increase if_iqdrop in the first case and if_ierrors in the second. But I think it makes sense to only use if_iqdrop for packets that we actively drop in the network stack.
