RE: [PATCH 08/23] e1000: add multicast stats counters
> Williams, Mitch A wrote:
> >>> + { "rx_broadcast", E1000_STAT(stats.bprc) },
> >>> + { "tx_broadcast", E1000_STAT(stats.bptc) },
> >>> + { "rx_multicast", E1000_STAT(stats.mprc) },
> >>> + { "tx_multicast", E1000_STAT(stats.mptc) },
> >>> { "rx_errors", E1000_STAT(net_stats.rx_errors) },
> >>> { "tx_errors", E1000_STAT(net_stats.tx_errors) },
> >>> { "tx_dropped", E1000_STAT(net_stats.tx_dropped) },
> >> NAK -- you also need to remove the standard net stats, which are
> >> exported elsewhere
> >
> > Jeff, can you please explain the reason for this NAK a little more?
> > Neither Auke nor I understand why you rejected the patch.
> >
> > This patch just adds the display of a few more stats in Ethtool. It
> > doesn't affect any other counters, and is really just a convenience
> > feature. I added this to the driver because of a customer request.
>
> Adding those stats is fine. You guys just need to remove the existing
> mess first.
>
> Jeff
>
Since we have 1-to-1 mapping of some of our statistics registers to the
net_stats, we could s/net_stats/stats/. However, there are a few
net_stats (e.g. net_stats.rx_errors) that encapsulate more than one
e1000 statistic register of which we don't have a private stat member
defined.
For those statistics, is it really necessary to add another stat
structure just to rm "net_stats" from that list we pass to ethtool? At
best, it would look something like this...
{ "foo_count", E1000_STAT(stats.foo) },
- { "rx_errors", E1000_STAT(net_stats.rx_errors) },
+ { "rx_errors", E1000_STAT(eth_stats.rx_errors) },
{ "bar_count", E1000_STAT(stats.bar) },
If so, well, OK. I'm just scratching my head as to why it's a "mess"
as-is.
I've missed obvious alternatives before; care to enlighten?
-Jeb
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Patch: Asynchronous IPI and e1000 Multiple Queues (aka ReceiveSide Scaling)
Davem brought up the point of how expensive IPIs are. Our own performance tests for multi-queue weren't all that impressive...which just proved his point. So we decided not to go forward with the patch. Really, the hardware we coded multi-queue for was not ready for such a feature. Hardware that supports MSI-X is really what makes sense for multi-queue. Since the 8257x hardware was the first family to support multi-queue, all previous hardware generations (PCI or PCI-X) would not have benefited from that patch. Thanks, -Jeb > -Original Message- > From: Piet Delaney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 6:41 PM > To: cramerj; netdev@vger.kernel.org > Cc: Piet Delaney; David Miller; Stephen Hemminger; Subhachandra Chandra > Subject: Re: Patch: Asynchronous IPI and e1000 Multiple Queues (aka > ReceiveSide Scaling) > > On Wed, 2006-08-16 at 18:33 -0700, Piet Delaney wrote: > > I came across your Sept 2005 LKML and NetDev posting: > > > > http://lwn.net/Articles/152989/ > > > > and was wondering what's been going on with this > > since your posting. Looks like an interesting > > patch that may be useful in our environment. > > I just noticed this is for PCI-Express. Has anything > similar been done for PCI-X? > > -piet > > > > > -piet > > > -- > Piet Delaney > BlueLane Teck > W: (408) 200-5256; [EMAIL PROTECTED] > H: (408) 243-8872; [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: e1000 not working on AMD64
Does /proc/interrupts show the interrupts incrementing for the interface? -Jeb > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Hajo Noerenberg > Sent: Tuesday, February 07, 2006 3:22 AM > To: netdev@vger.kernel.org > Subject: e1000 not working on AMD64 > > > I've bought four new e1000 cards (PCI id 8086:107c, chip label 82541PI), > three of them are working without problems (i386, kernel 2.4.x). > > One of them is installed in an AMD64 SMP system (Athlon dual core 4GB). > It gets detected, link is reported to be up, but no data goes through > (in fact _sometimes_ it succeeds to get an IP adress via DHCP after > 10-20 retries). If I set an IP manually, I am not able to ping any other > host (ping sizes 30bytes ... 1000bytes). > > Tested on kernel 2.6.15, 2.6.16-rc2 and 2.6.16-rc2-git2. > > (Un-)setting NAPI does not change anything. > > Initially I assumed an IRQ-related issue, but the 3ware RAID controller > works without any problems. > > Hajo > > > +++ > > :00:00.0 RAM memory: nVidia Corporation: Unknown device 02f1 (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Capabilities: [44] #08 [01e0] > Capabilities: [e0] #08 [a800] > > :00:00.1 RAM memory: nVidia Corporation: Unknown device 02fa (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > :00:00.2 RAM memory: nVidia Corporation: Unknown device 02fe (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > :00:00.3 RAM memory: nVidia Corporation: Unknown device 02f8 (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- > :00:00.4 RAM memory: nVidia Corporation: Unknown device 02f9 (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > > :00:00.5 RAM memory: nVidia Corporation: Unknown device 02ff (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Capabilities: [44] #00 [00fe] > Capabilities: [fc] #00 [] > > :00:00.6 RAM memory: nVidia Corporation: Unknown device 027f (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR+ FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > :00:00.7 RAM memory: nVidia Corporation: Unknown device 027e (rev a2) > Subsystem: Asustek Computer, Inc.: Unknown device 81bf > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- > :00:02.0 PCI bridge: nVidia Corporation: Unknown device 02fc (rev > a1) (prog-if 00 [Normal decode]) > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > I/O behind bridge: f000-0fff > Memory behind bridge: fff0-000f > Prefetchable memory behind bridge: fff0- > > BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- > Capabilities: [40] #0d [] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [50] Message Signalled Interrupts: 64bit+ > Queue=0/1 Enable- > Address: Data: > Capabilities: [60] #08 [a800] >
RE: [PATCH ] ethtool: Remove duplex info from CTRL register dump
> > applied, after replacing "ethtool:" with "e1000:" in the subject line. Even if it's modifying the ethtool app? As long as it doesn't confuse your scripts, I suppose. -Jeb - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2.6.13-rc3] ethtool: add generic ethtool_op_get_perm_addr routine
B'ah! Nevermind. I'll learn to read #defines one of these days.
Sorry for the spam.
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of cramerj
> Sent: Wednesday, July 27, 2005 6:45 PM
> To: John W. Linville; Jon Wetzel
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: RE: [patch 2.6.13-rc3] ethtool: add generic
> ethtool_op_get_perm_addr routine
>
> Stupid question: Can we assume ethtool will only be used for
networking
> devices with a 6-byte hardware address?
>
> If not, then the driver-specific approach would give the flexibility
of
> copying anything up to MAX_ADDR_LEN.
>
> Perhaps increasing the count to MAX_ADDR_LEN is the way to go??
>
> 6/half-dozen
>
> -Jeb
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > On Behalf Of John W. Linville
> > Sent: Wednesday, July 27, 2005 6:15 PM
> > To: Jon Wetzel
> > Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> > Subject: [patch 2.6.13-rc3] ethtool: add generic
> ethtool_op_get_perm_addr
> > routine
> >
> > Add generic ethtool operation for getting permanenet hardware
address.
> >
> > Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> > ---
> > This moves and renames the basically generic e1000_get_perm_addr
> > routine to ethtool_op_get_perm_addr, and causes e1000 to make use of
> > the new name.
> >
> > drivers/net/e1000/e1000_ethtool.c |9 +
> > include/linux/ethtool.h |1 +
> > net/core/ethtool.c|7 +++
> > 3 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/e1000/e1000_ethtool.c
> > b/drivers/net/e1000/e1000_ethtool.c
> > --- a/drivers/net/e1000/e1000_ethtool.c
> > +++ b/drivers/net/e1000/e1000_ethtool.c
> > @@ -1704,13 +1704,6 @@ e1000_get_strings(struct net_device *net
> > }
> > }
> >
> > -static int
> > -e1000_get_perm_addr(struct net_device *netdev, struct ethtool_addr
> *eaddr)
> > -{
> > - memcpy(eaddr->addr, netdev->perm_addr, ETH_MAX_ADDR_LEN);
> > - return 0;
> > -}
> > -
> > struct ethtool_ops e1000_ethtool_ops = {
> > .get_settings = e1000_get_settings,
> > .set_settings = e1000_set_settings,
> > @@ -1746,7 +1739,7 @@ struct ethtool_ops e1000_ethtool_ops = {
> > .phys_id= e1000_phys_id,
> > .get_stats_count= e1000_get_stats_count,
> > .get_ethtool_stats = e1000_get_ethtool_stats,
> > - .get_perm_addr = e1000_get_perm_addr,
> > + .get_perm_addr = ethtool_op_get_perm_addr,
> > };
> >
> > void e1000_set_ethtool_ops(struct net_device *netdev)
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -268,6 +268,7 @@ u32 ethtool_op_get_sg(struct net_device
> > int ethtool_op_set_sg(struct net_device *dev, u32 data);
> > u32 ethtool_op_get_tso(struct net_device *dev);
> > int ethtool_op_set_tso(struct net_device *dev, u32 data);
> > +int ethtool_op_get_perm_addr(struct net_device *dev, struct
> ethtool_addr
> > *);
> >
> > /**
> > * ðtool_ops - Alter and report network device settings
> > diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> > --- a/net/core/ethtool.c
> > +++ b/net/core/ethtool.c
> > @@ -81,6 +81,12 @@ int ethtool_op_set_tso(struct net_device
> > return 0;
> > }
> >
> > +int ethtool_op_get_perm_addr(struct net_device *netdev, struct
> > ethtool_addr *eaddr)
> > +{
> > + memcpy(eaddr->addr, netdev->perm_addr, ETH_MAX_ADDR_LEN);
> > + return 0;
> > +}
> > +
> > /* Handlers for each ethtool command */
> >
> > static int ethtool_get_settings(struct net_device *dev, void __user
> > *useraddr)
> > @@ -845,6 +851,7 @@ int dev_ethtool(struct ifreq *ifr)
> >
> > EXPORT_SYMBOL(dev_ethtool);
> > EXPORT_SYMBOL(ethtool_op_get_link);
> > +EXPORT_SYMBOL_GPL(ethtool_op_get_perm_addr);
> > EXPORT_SYMBOL(ethtool_op_get_sg);
> > EXPORT_SYMBOL(ethtool_op_get_tso);
> > EXPORT_SYMBOL(ethtool_op_get_tx_csum);
> > --
> > John W. Linville
> > [EMAIL PROTECTED]
> > -
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 2.6.13-rc3] ethtool: add generic ethtool_op_get_perm_addr routine
Stupid question: Can we assume ethtool will only be used for networking
devices with a 6-byte hardware address?
If not, then the driver-specific approach would give the flexibility of
copying anything up to MAX_ADDR_LEN.
Perhaps increasing the count to MAX_ADDR_LEN is the way to go??
6/half-dozen
-Jeb
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of John W. Linville
> Sent: Wednesday, July 27, 2005 6:15 PM
> To: Jon Wetzel
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: [patch 2.6.13-rc3] ethtool: add generic
ethtool_op_get_perm_addr
> routine
>
> Add generic ethtool operation for getting permanenet hardware address.
>
> Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
> ---
> This moves and renames the basically generic e1000_get_perm_addr
> routine to ethtool_op_get_perm_addr, and causes e1000 to make use of
> the new name.
>
> drivers/net/e1000/e1000_ethtool.c |9 +
> include/linux/ethtool.h |1 +
> net/core/ethtool.c|7 +++
> 3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_ethtool.c
> b/drivers/net/e1000/e1000_ethtool.c
> --- a/drivers/net/e1000/e1000_ethtool.c
> +++ b/drivers/net/e1000/e1000_ethtool.c
> @@ -1704,13 +1704,6 @@ e1000_get_strings(struct net_device *net
> }
> }
>
> -static int
> -e1000_get_perm_addr(struct net_device *netdev, struct ethtool_addr
*eaddr)
> -{
> - memcpy(eaddr->addr, netdev->perm_addr, ETH_MAX_ADDR_LEN);
> - return 0;
> -}
> -
> struct ethtool_ops e1000_ethtool_ops = {
> .get_settings = e1000_get_settings,
> .set_settings = e1000_set_settings,
> @@ -1746,7 +1739,7 @@ struct ethtool_ops e1000_ethtool_ops = {
> .phys_id= e1000_phys_id,
> .get_stats_count= e1000_get_stats_count,
> .get_ethtool_stats = e1000_get_ethtool_stats,
> - .get_perm_addr = e1000_get_perm_addr,
> + .get_perm_addr = ethtool_op_get_perm_addr,
> };
>
> void e1000_set_ethtool_ops(struct net_device *netdev)
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -268,6 +268,7 @@ u32 ethtool_op_get_sg(struct net_device
> int ethtool_op_set_sg(struct net_device *dev, u32 data);
> u32 ethtool_op_get_tso(struct net_device *dev);
> int ethtool_op_set_tso(struct net_device *dev, u32 data);
> +int ethtool_op_get_perm_addr(struct net_device *dev, struct
ethtool_addr
> *);
>
> /**
> * ðtool_ops - Alter and report network device settings
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -81,6 +81,12 @@ int ethtool_op_set_tso(struct net_device
> return 0;
> }
>
> +int ethtool_op_get_perm_addr(struct net_device *netdev, struct
> ethtool_addr *eaddr)
> +{
> + memcpy(eaddr->addr, netdev->perm_addr, ETH_MAX_ADDR_LEN);
> + return 0;
> +}
> +
> /* Handlers for each ethtool command */
>
> static int ethtool_get_settings(struct net_device *dev, void __user
> *useraddr)
> @@ -845,6 +851,7 @@ int dev_ethtool(struct ifreq *ifr)
>
> EXPORT_SYMBOL(dev_ethtool);
> EXPORT_SYMBOL(ethtool_op_get_link);
> +EXPORT_SYMBOL_GPL(ethtool_op_get_perm_addr);
> EXPORT_SYMBOL(ethtool_op_get_sg);
> EXPORT_SYMBOL(ethtool_op_get_tso);
> EXPORT_SYMBOL(ethtool_op_get_tx_csum);
> --
> John W. Linville
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
