On 26 Jan 2014, at 11:31 am, Brad Smith <[email protected]> wrote: > On 31/12/13 5:50 AM, Mike Belopuhov wrote: >> On 31 December 2013 09:46, Brad Smith <[email protected]> wrote: >>> On 31/12/13 3:14 AM, Mark Kettenis wrote: >>>>> >>>>> Date: Tue, 31 Dec 2013 01:28:04 -0500 >>>>> From: Brad Smith <[email protected]> >>>>> >>>>> Don't count RX overruns and missed packets as inputs errors. They're >>>>> expected to increment when using MCLGETI. >>>>> >>>>> OK? >>>> >>>> >>>> These may be "expected", but they're still packets that were not >>>> received. And it is useful to know about these, for example when >>>> debugging TCP performance issues. >>> >>> >>> Well do we want to keep just the missed packets or both? Part of the >>> diff was inspired by this commit when I was looking at what counters >>> were incrementing.. >>> >>> for bge(4).. >>> >>> revision 1.334 >>> date: 2013/06/06 00:05:30; author: dlg; state: Exp; lines: +2 -4; >>> dont count rx ring overruns as input errors. with MCLGETI controlling the >>> ring we expect to run out of rx descriptors as a matter of course, its not >>> an error. >>> >>> ok mikeb@ >>> >>> >> >> it does screws up statistics big time. does mpc counter follow rx_overruns? >> why did we add them up both previously? > > Yes, it does. I can't say why exactly but before MCLGETI for most > environments it was unlikely to have RX overruns.
its not obvious? rx rings are usually massively over provisioned. eg, my myx has 512 entries in its rx ring. however, its interrupt mitigation is currently configured for approximately 16k interrupts a second. if you're sustaining 1m pps, then you can divide that by the interrupt rate to figure out the average usage of the rx ring. so 1000 / 16 is about 60-65 descriptors per interrupt. 512 is roughly an order of magnitude more than what you need for that workload. if you were hitting the ring limits before MCLGETI, then that means you dont have enough cpu to process the pps. increasing the ring size would make it worse cos you'd spend more time freeing mbufs because you were too far behind on the pps you could deal with. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >
