Date:	Wed, 6 May 2009 01:11:04 -0700 (Pacific Daylight Time)
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Jesper Dangaard Brouer <hawk@...x.dk>
cc:	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>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...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 Tue, 2009-05-05 at 14:35 -0700, David Miller wrote:
> > From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
> > Date: Tue, 5 May 2009 14:32:04 -0700
> > 
> > > the manual[1] for the hardware says:
> > > RNBC:
> > > This register counts the number of times that frames were received
> > > when there were no available buffers in host memory to store those
> > > frames (receive descriptor head and tail pointers were equal). The
> > > packet is still received if there is space in the FIFO. This register
> > > only increments if receives are enabled. This register does not
> > > increment when flow control packets are received.
> > > 
> > > The critical bit "The packet is still received if there is space in
> > > the FIFO" (AND a host memory buffer becomes available) So the reason
> > > we don't want to put it in the net_stats stats for drops is that the
> > > packet
> > > *wasn't* necessarily dropped.
> > > 
> > > The rx_missed errors is for packets that were definitely dropped, and
> > > is already stored in the net_stats structure.
> > 
> > While not an "rx_missed" because we do eventually take the
> > packet, conceptually it is a "fifo overflow" in the sense
> > that we exceeded available receive resources at the time that
> > the packet arrived.
> 
> Yes, with this argumentation, the MPC should then be kept as "rx_missed"
> packets.  And the RNBC stored as "rx_fifo_errors" as its an overflow
> indication, not a number of packets dropped.

The way RNBC works depends on how the queues themselves are configured.  
Specifically, if you have packet drop enabled per queue or not will affect 
RNBC.

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.

If bit 31 in SRRCTL is 0b, then if there's no room in the packet buffer
(no more descriptors available), the device tries to store the packet in
the FIFO.  RNBC will *not* be incremented in this case.  If there's no space
in the FIFO, then the packet is dropped.  RNBC still is not incremented in this
case, rather MPC will be incremented, since the packet was dropped due to the FIFO 
being full.

In 82576, according to the manual, SRRCTL bit 31 is 0b for queue 0 by 
default, and is 1b for all other queues by default.

I hope this helps explain what the hardware is doing, and how these two 
counters get used in overrun cases.

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