From: linas@austin.ibm.com (Linas Vepstas)
To: "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jesse.brandeburg@intel.com, linuxppc-dev@ozlabs.org,
john.ronciak@intel.com, jeffrey.t.kirsher@intel.com,
linux-pci@atrey.karlin.mff.cuni.cz,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
Date: Thu, 30 Mar 2006 18:35:06 -0600 [thread overview]
Message-ID: <20060331003506.GU2172@austin.ibm.com> (raw)
In-Reply-To: <442C8069.507@wolfmountaingroup.com>
On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
>
> Linas Vepstas wrote:
Well, these comments have nothing to do with my patch, but ...
anyway ...
> The driver also needs to be fixed to allow clearing of the stats (like
> all the other adapter drivers). At present, when I run performance
> and packet drop counts on the cards, I cannot reset the stats with this
> code because the driver stores them in the e100_adapter
> structure. This is busted.
>
> This function:
>
> int clear_network_device_stats(BYTE *name)
I couldn't find such a function in the kernel.
> does not work on e1000 due to this section of code:
>
> void
> e1000_update_stats(struct e1000_adapter *adapter)
> {
>
> adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
> adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
These are hardware stats ... presumably useless without
a detailed understanding of the guts of the e1000.
> //NOTE These stats need to be stored in the stats structure so they can
> be cleared by
> statistics monitoring programs.
I can't imagine what generic interface would allow these
to be viewed.
> /* Fill out the OS statistics structure */
>
> adapter->net_stats.rx_packets = adapter->stats.gprc;
> adapter->net_stats.tx_packets = adapter->stats.gptc;
> adapter->net_stats.rx_bytes = adapter->stats.gorcl;
> adapter->net_stats.tx_bytes = adapter->stats.gotcl;
Now *these* are generic ... and fixing this so that the
stats increment instead of over-riding would take
maybe half-an-hour or so; this is not hard to do ... !?
Do you want me to write a patch to do this?
--linas
WARNING: multiple messages have this Message-ID (diff)
From: linas@austin.ibm.com (Linas Vepstas)
To: "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com>
Cc: john.ronciak@intel.com, jesse.brandeburg@intel.com,
jeffrey.t.kirsher@intel.com, Jeff Garzik <jgarzik@pobox.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@atrey.karlin.mff.cuni.cz, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH]: e1000: prevent statistics from getting garbled during reset.
Date: Thu, 30 Mar 2006 18:35:06 -0600 [thread overview]
Message-ID: <20060331003506.GU2172@austin.ibm.com> (raw)
In-Reply-To: <442C8069.507@wolfmountaingroup.com>
On Thu, Mar 30, 2006 at 06:05:45PM -0700, Jeff V. Merkey wrote:
>
> Linas Vepstas wrote:
Well, these comments have nothing to do with my patch, but ...
anyway ...
> The driver also needs to be fixed to allow clearing of the stats (like
> all the other adapter drivers). At present, when I run performance
> and packet drop counts on the cards, I cannot reset the stats with this
> code because the driver stores them in the e100_adapter
> structure. This is busted.
>
> This function:
>
> int clear_network_device_stats(BYTE *name)
I couldn't find such a function in the kernel.
> does not work on e1000 due to this section of code:
>
> void
> e1000_update_stats(struct e1000_adapter *adapter)
> {
>
> adapter->stats.xofftxc += E1000_READ_REG(hw, XOFFTXC);
> adapter->stats.fcruc += E1000_READ_REG(hw, FCRUC);
These are hardware stats ... presumably useless without
a detailed understanding of the guts of the e1000.
> //NOTE These stats need to be stored in the stats structure so they can
> be cleared by
> statistics monitoring programs.
I can't imagine what generic interface would allow these
to be viewed.
> /* Fill out the OS statistics structure */
>
> adapter->net_stats.rx_packets = adapter->stats.gprc;
> adapter->net_stats.tx_packets = adapter->stats.gptc;
> adapter->net_stats.rx_bytes = adapter->stats.gorcl;
> adapter->net_stats.tx_bytes = adapter->stats.gotcl;
Now *these* are generic ... and fixing this so that the
stats increment instead of over-riding would take
maybe half-an-hour or so; this is not hard to do ... !?
Do you want me to write a patch to do this?
--linas
next prev parent reply other threads:[~2006-03-31 0:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-30 21:39 [PATCH]: e1000: prevent statistics from getting garbled during reset Linas Vepstas
2006-03-30 21:39 ` Linas Vepstas
2006-03-31 0:02 ` Linas Vepstas
2006-03-31 0:02 ` Linas Vepstas
2006-03-31 1:05 ` Jeff V. Merkey
2006-03-31 1:05 ` Jeff V. Merkey
2006-03-31 0:35 ` Linas Vepstas [this message]
2006-03-31 0:35 ` Linas Vepstas
2006-03-31 4:14 ` Jeffrey V. Merkey
2006-03-31 4:14 ` Jeffrey V. Merkey
2006-03-31 17:03 ` Linas Vepstas
2006-03-31 17:03 ` Linas Vepstas
2006-03-31 17:36 ` Rick Jones
2006-03-31 17:36 ` Rick Jones
2006-03-31 18:40 ` Jeff V. Merkey
2006-03-31 18:40 ` Jeff V. Merkey
2006-03-31 5:46 ` Greg KH
2006-03-31 5:46 ` Greg KH
2006-03-31 17:06 ` Linas Vepstas
2006-03-31 17:06 ` Linas Vepstas
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=20060331003506.GU2172@austin.ibm.com \
--to=linas@austin.ibm.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=jgarzik@pobox.com \
--cc=jmerkey@wolfmountaingroup.com \
--cc=john.ronciak@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
/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.