All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <hawk@comx.dk>
To: "Ronciak, John" <john.ronciak@intel.com>
Cc: Jesper Dangaard Brouer <hawk@diku.dk>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	netdev <netdev@vger.kernel.org>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
	"Allan, Bruce W" <bruce.w.allan@intel.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [PATCH] igb: Record hardware RX overruns in net_stats
Date: Wed, 06 May 2009 10:12:42 +0200	[thread overview]
Message-ID: <1241597562.5172.25.camel@localhost.localdomain> (raw)
In-Reply-To: <273D38FBE7C6FE46A1689FCD014A0B8B49655903@azsmsx505.amr.corp.intel.com>

On Tue, 2009-05-05 at 15:38 -0700, Ronciak, John wrote:
> >Its really useful for diagnosing problems, and I'm betting 
> >that this is a real-life situation which people is going to experience. We 
> >might as well help our self to more easily identify this issue when people 
> >report drop problems.
>
> The problem is that the RNBC aren't dropped packets as the numbers you
> have show.  

Just to make it clear, I am experiencing dropped packets.  The reason I
positivly know this, is that I'm writing a MPEG2-TS drop detection
netfilter module.  Which were the only reason I discovered the packet
drops and the "hidden" RNBC counter via ethtool.

I have read the datasheeet, and with Jeffrey's detailed explaination, I
do know that this number might be higher than the actually drops I'm
experiencing.


> While we can agree that the MPC are the actual dropped packets and
> could eaily be be used in the fifo overflow count since the packets
> were really dropped.

Well, then I think we should keep MPC as drops, and use the fifo_errors
as an fifo overflow indication containing RNBC count.


> > I think that both MPC and RNBC should be stored in rx_fifo_errors
> > (and of cause still keeping them seperate to ethtool -S).
>
> This would count RNBC packets as packets that the stack did not
> process, which it did.  The MPC packets were not processed by the
> stack and should be counted as dropped.  As you point out, both counts
> are available via ethtool -S.
> 
> >I'll post two patches with these changes tomorrow, for you evaluation.
>
> Thanks, we look forward to see them.

I'll keep it to one patch (with an extra comment reflecting this
disscussion), as you have convinced me that the MPC should stay as
"rx_missed", as this is presented to userspace as a positive drop.


-- 
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


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

  reply	other threads:[~2009-05-06  8:12 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
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 [this message]
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=1241597562.5172.25.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.