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] [day] [month] [year] [list]
Date:	Wed, 6 May 2009 14:24:54 -0700 (Pacific Daylight Time)
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Jesper Dangaard Brouer <jdb@...x.dk>
cc:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	David Miller <davem@...emloft.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"hawk@...u.dk" <hawk@...u.dk>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: [PATCH] igb: Record hardware RX overruns in net_stats

On Wed, 6 May 2009, Jesper Dangaard Brouer wrote:

> On Wed, 2009-05-06 at 15:09 +0200, Jesper Dangaard Brouer wrote:
> > > In the SRRCTL registers, there is a DROP_EN bit, bit 31.  If this 
> > > bit is set to 1b for the queue in question, then the packet will be 
> > > dropped when there are no buffers in the packet buffer.  This does
> > not 
> > > mean the FIFO is full or has been overrun, it just means there's no
> > more
> > > descriptors available in the Rx ring for that queue.  In this case,
> > RNBC 
> > > is incremented, MPC is not.
> > 
> > My experience is that if DROP_EN bit is *set*. Then I cannot find the
> > drop count anywhere... not in RNBC and not in MPC ... and I can still
> > see the drops with my netfilter module mp2t.
> > 
> > ethtool -S eth21 | egrep 'rx_no_buffer_count|rx_miss'
> >      rx_no_buffer_count: 0
> >      rx_missed_errors: 0
> > 
> > I'm guessing that the drop counters are now in the per queue RQDPC
> > register (Receive Queue Drop Packet Count), but reading that is not
> > implemented in the driver. 
> 
> Just did a quick implemenation in the driver, see draft patch below (not
> ready for inclusion yet!).
> 
> An my guess was correct, the drops count is stored per queue in RQDPC.
> The only really anoying thing is that this counter is only 12 bit, thus
> overruns can occur quickly.  (This reminds me of my drop count
> implemenation for Sun niu driver.  This counter has less bits that the 
> Sun counter, but at least it automatically clears on reads)
> 
> I'll post some more clean patches tomorrow...

Ok, so 82576 is much more like 82599 with the queue counters, but 
different enough to be annoying.  Yes, I'm seeing this in the data manual 
for 82576.  Honestly, we have too many damn counters for packet 
accounting.  I'm very happy you're getting what you wanted now.  Your 
patch looks reasonable to me; please let us know if you have any other 
questions about the part that we might be able to help with.

Cheers,
-PJ Waskiewicz
--
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