All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <hawk@comx.dk>
To: David Miller <davem@davemloft.net>
Cc: jeffrey.t.kirsher@intel.com, hawk@diku.dk,
	netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
	jesse.brandeburg@intel.com, bruce.w.allan@intel.com,
	peter.p.waskiewicz.jr@intel.com, john.ronciak@intel.com
Subject: Re: [PATCH] igb: Record hardware RX overruns in net_stats
Date: Wed, 06 May 2009 09:46:33 +0200	[thread overview]
Message-ID: <1241595993.5172.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20090505.143529.148721206.davem@davemloft.net>

On Tue, 2009-05-05 at 14:35 -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.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.

-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer


  reply	other threads:[~2009-05-06  7:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 11:06 [PATCH] igb: Record hardware RX overruns in net_stats Jesper Dangaard Brouer
2009-05-05 18:47 ` Jeff Kirsher
2009-05-05 18:58   ` David Miller
2009-05-05 21:24     ` Jesper Dangaard Brouer
2009-05-05 21:32       ` Jeff Kirsher
2009-05-05 21:35         ` David Miller
2009-05-06  7:46           ` Jesper Dangaard Brouer [this message]
2009-05-06  8:11             ` Waskiewicz Jr, Peter P
2009-05-06 13:09               ` Jesper Dangaard Brouer
2009-05-06 20:59                 ` Jesper Dangaard Brouer
2009-05-06 21:24                   ` Waskiewicz Jr, Peter P
2009-05-05 22:38       ` Ronciak, John
2009-05-06  8:12         ` Jesper Dangaard Brouer
2009-05-06  8:56           ` [PATCH v2] igb: Record host memory receive overflow " Jesper Dangaard Brouer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1241595993.5172.4.camel@localhost.localdomain \
    --to=hawk@comx.dk \
    --cc=bruce.w.allan@intel.com \
    --cc=davem@davemloft.net \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=hawk@diku.dk \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.