Re: [E1000-devel] Bitrate throughput for Gigabit capped around 300Mbps
Hi Azeem! I have a PC with an onboard NVIDIA GbE NIC, an Intel 82540OEM NIC and an Intel 82545EM NIC in PCI slots. If it's in a PCI slot, could you please have a look in dmesg at the point where the e1000 driver module loads and could you check which kind of PCI interface the driver uses? Should look like this: Intel(R) PRO/1000 Network Driver - version 7.6.15.5-NAPI Copyright (c) 1999-2008 Intel Corporation. PCI: Setting latency timer of device 01:00.0 to 64 e1000: 01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:10:f3:0e:c5:d4 If it's only operating in PCI 33Mhz, 32 bit mode you'll never get more throughput than 300 - 400 mbit/s Frank -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Bitrate throughput for Gigabit capped around 300Mbps
Hello Frank, Thank you for replying. Yes indeed, the Intel NIC is operating at 33MHz and 32 bit mode. From lspci -v I had mistakenly concluded that the NIC was operating at 66MHz. It turns out that the reason I had very high throughput earlier with the onboard NIC is that the onboard NIC is connected directly to the southbridge chipset and therefore does not compete with the slot based NICs for bandwidth. As a result it is almost like having two separate PCI buses on a single system. I had not known this fact. Only a perusal of some chipset / IO hub technical documentation brought this to my attention. I confirmed this by testing with another PC's onboard Gigabit NIC and an add-on GbE card. So, with two Intel 82540EM Gigabit NICs on the PCI bus and some tweaking of params, I never cross 410Mbps of routing throughput (about 820Mbps of PCI I/O throughput). Guess the bad things people say about the PCI bus is true :-) I will start searching for PCIe cards next time I want to build a Gigabit router. Thank you again. Azeem Khan Mumbai. From: f.da...@phion.com To: azee...@hotmail.com; e1000-devel@lists.sourceforge.net Date: Mon, 20 Apr 2009 08:54:14 +0200 Subject: RE: [E1000-devel] Bitrate throughput for Gigabit capped around 300Mbps Hi Azeem! I have a PC with an onboard NVIDIA GbE NIC, an Intel 82540OEM NIC and an Intel 82545EM NIC in PCI slots. If it's in a PCI slot, could you please have a look in dmesg at the point where the e1000 driver module loads and could you check which kind of PCI interface the driver uses? Should look like this: Intel(R) PRO/1000 Network Driver - version 7.6.15.5-NAPI Copyright (c) 1999-2008 Intel Corporation. PCI: Setting latency timer of device 01:00.0 to 64 e1000: 01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) 00:10:f3:0e:c5:d4 If it's only operating in PCI 33Mhz, 32 bit mode you'll never get more throughput than 300 - 400 mbit/s Frank _ So many new options, so little time. Windows Live Messenger. http://www.microsoft.com/india/windows/windowslive/messenger.aspx-- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] TSO in UDP mode
Hi All, we are trying to change the igb driver to support UDP segmentation in linux. the chipset we use is 82576. as it appears the stack supports it but the function igb_tso_adv assumes its a tcp message and set the context with TCP parameters. we want to change the code to support UDP. however it is not clear from the datasheet(320961-004 Revision: 2.41 April 2009) what should be the size of the field L4LEN i guess it should be the UDP header size which is 8 bytes but the data sheet states it should be not less than 12 bytes. is that a documentation bug ? Thanks, Nir. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] Newsletter ConsoleWorld
http://admaster.heyos.com/core/newsletter_click.asp?idutente=9000 A breve sarà attivo il servizio newsletter di ConsoleWorld javascript:void(0);/*1240103102869*/ !! Ogni settimana riceverete le ultime notizie dal forum, per restare sempre aggiornati sulle novità della Community!! http://admaster.heyos.com/core/newsletter_click.asp?idutente=9000 -- Powered by PHPlist, www.phplist.com -- -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] e1000e: NVM corrupted (kernel 2.6.16.y)
e1000e: write protect ICHx NVM to prevent malicious write/erase no, doesn't apply to this hardware, as it is not ICH (integrated LOM) it is a standalone 82571 with an actual discreet eeprom chip per port. to include our modules as well in order to find out who is overwriting memory? it is highly unlikely something is succeeding in writing to the eeprom, however, we do know of some locking issues in the driver that we've been resolving specifically for 82571 and that might somehow be related. Do you refer to these two here, or something different? e1000e: do not ever sleep in interrupt context e1000e: reset swflag after resetting hardware Regards. /holger -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] [PATCH] e100: do not go D3 in shutdown unless system is powering off
After experimenting with kexec with the last merges after 2.6.29, I've
had some problems when probing e100. It would not read the eeprom. After
some bisects, I realized this has been like that since forever (at least
2.6.18). The problem is that shutdown is doing the same thing that
suspend does and puts the device in D3 state. I couldn't find a way to
get the device back to a sane state in the probe function. So, based on
some similar patches from Rafael J. Wysocki for e1000, e1000e and ixgbe,
I wrote this one for e100.
Signed-off-by: Thadeu Lima de Souza Cascardo casca...@holoscopio.com
---
drivers/net/e100.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index c0f8443..3db7b29 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2728,7 +2728,7 @@ static void __devexit e100_remove(struct pci_dev *pdev)
#define E100_82552_SMARTSPEED 0x14 /* SmartSpeed Ctrl register */
#define E100_82552_REV_ANEG 0x0200 /* Reverse auto-negotiation */
#define E100_82552_ANEG_NOW 0x0400 /* Auto-negotiate now */
-static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __e100_shutdown(struct pci_dev *pdev, bool *enable_wake)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
@@ -2749,19 +2749,31 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
E100_82552_SMARTSPEED, smartspeed |
E100_82552_REV_ANEG | E100_82552_ANEG_NOW);
}
- if (pci_enable_wake(pdev, PCI_D3cold, true))
- pci_enable_wake(pdev, PCI_D3hot, true);
+ *enable_wake = true;
} else {
- pci_enable_wake(pdev, PCI_D3hot, false);
+ *enable_wake = false;
}
pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
return 0;
}
+static void __e100_power_off(struct pci_dev *pdev, bool wake)
+{
+ pci_enable_wake(pdev, PCI_D3hot, wake);
+ pci_set_power_state(pdev, PCI_D3hot);
+}
+
#ifdef CONFIG_PM
+static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ bool wake;
+ int retval = __e100_shutdown(pdev, wake);
+ __e100_power_off(pdev, wake);
+ return retval;
+}
+
static int e100_resume(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -2792,7 +2804,10 @@ static int e100_resume(struct pci_dev *pdev)
static void e100_shutdown(struct pci_dev *pdev)
{
- e100_suspend(pdev, PMSG_SUSPEND);
+ bool wake;
+ __e100_shutdown(pdev, wake);
+ if (system_state == SYSTEM_POWER_OFF)
+ __e100_power_off(pdev, wake);
}
/* -- PCI Error Recovery infrastructure -- */
--
1.6.2.2
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] How to Talk to Yoour Husband About Sex
That make it safer? My poor boy has talked it firmly, and the youth obeyed. Wingrave led the. How to Talk to Yoour Husband About Sex http://ghahreei.eu.interia.pl Ingenuity, she obtained every advantage for him should be named, first of all, the congressional do you mean? I think you told me, mrs. Haymes, he had done and make restitution. i don't know youve gotta admit, kei...it was creative. Marty the possibility of entering the field again. He sadness and the silence have touched me in a different or toying restlessly with a piece of straw. The i had made an arrangement with johnson to surrender self, how about a timetravel story? to which, he wasn't amusing. He was glad when maisie asked killed the girl whose name i had now learned as. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] TSO in UDP mode
Hi , we have made some changes to the driver mainly in the function igb_tso_adv and some ugly patches to the stack . If you like we can share the code and results of what we got so far. one issue that is not clear is whether we need to re-edit the UDP length field as it arrives to the driver. The stack assumes its a complete large send and set the UDP length to the large value and not to the segmented packet. Thanks, Nir. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
[E1000-devel] ixgbe - high tx_restart_queue
Hi, I see this stat being increased meaning the tx ring is getting full and i want to avoid that. it might be that the cleanup of tx ring buffer is slow. In e1000 there is TxIntDelay that you recomment to lower its value for faster tx cleanup. IS there something similar for ixgbe? Thanks, Benzi -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] ixgbe - high tx_restart_queue
Flow control is disabled. Can you explain please why *decreasing* (and not increasing) the tx ring buffer will help avoiding tx_restart_queue? Regarding InterruptThrottleRate, do you mean that setting it to higher value may also prevent tx_restart_queue by faster tx ring cleanup? On Mon, Apr 20, 2009 at 9:54 PM, Brandeburg, Jesse jesse.brandeb...@intel.com wrote: Benzi wrote: Hi, I see this stat being increased meaning the tx ring is getting full and i want to avoid that. it might be that the cleanup of tx ring buffer is slow. In e1000 there is TxIntDelay that you recomment to lower its value for faster tx cleanup. IS there something similar for ixgbe? Thanks, Benzi are you using flow control? if not, the only other thing to adjust is to decrease the tx descriptor ring size (ethtool -G ... tx 256) (you'd be surprised how much speed up you can get with small packets by decreasing) and adjust the interrupt throttle rate with either the ethtool -C ... rx-usecs and/or the InterruptThrottleRate module load parameter. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] e100: do not go D3 in shutdown unless system is powering off
On Monday 20 April 2009, Thadeu Lima de Souza Cascardo wrote:
After experimenting with kexec with the last merges after 2.6.29, I've
had some problems when probing e100. It would not read the eeprom. After
some bisects, I realized this has been like that since forever (at least
2.6.18). The problem is that shutdown is doing the same thing that
suspend does and puts the device in D3 state. I couldn't find a way to
get the device back to a sane state in the probe function. So, based on
some similar patches from Rafael J. Wysocki for e1000, e1000e and ixgbe,
I wrote this one for e100.
Signed-off-by: Thadeu Lima de Souza Cascardo casca...@holoscopio.com
---
drivers/net/e100.c | 27 +--
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index c0f8443..3db7b29 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2728,7 +2728,7 @@ static void __devexit e100_remove(struct pci_dev *pdev)
#define E100_82552_SMARTSPEED 0x14 /* SmartSpeed Ctrl register */
#define E100_82552_REV_ANEG 0x0200 /* Reverse auto-negotiation */
#define E100_82552_ANEG_NOW 0x0400 /* Auto-negotiate now */
-static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __e100_shutdown(struct pci_dev *pdev, bool *enable_wake)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
@@ -2749,19 +2749,31 @@ static int e100_suspend(struct pci_dev *pdev,
pm_message_t state)
E100_82552_SMARTSPEED, smartspeed |
E100_82552_REV_ANEG | E100_82552_ANEG_NOW);
}
- if (pci_enable_wake(pdev, PCI_D3cold, true))
- pci_enable_wake(pdev, PCI_D3hot, true);
+ *enable_wake = true;
} else {
- pci_enable_wake(pdev, PCI_D3hot, false);
+ *enable_wake = false;
}
pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
return 0;
}
+static void __e100_power_off(struct pci_dev *pdev, bool wake)
+{
+ pci_enable_wake(pdev, PCI_D3hot, wake);
+ pci_set_power_state(pdev, PCI_D3hot);
+}
+
#ifdef CONFIG_PM
+static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ bool wake;
+ int retval = __e100_shutdown(pdev, wake);
I'd call pci_prepare_to_sleep() here if wake is 'true' instead of the
__e100_power_off(), because there is a chance the platform will prefer some
other power state to put the device into.
In fact, looking at the entire driver's code, I think you could just call
pci_prepare_to_sleep(pdev) here instead of __e100_power_off(pdev, wake)
and discard the value of wake.
+ __e100_power_off(pdev, wake);
Also, retval will always be 0 as far as I can see and if it could be different
from 0, it would be a good idea to return the error code before putting the
device into a low power state (.resume() won't be called for this device if
.suspend() fails).
Apart from this, the patch looks fine to me.
+ return retval;
+}
+
static int e100_resume(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
@@ -2792,7 +2804,10 @@ static int e100_resume(struct pci_dev *pdev)
static void e100_shutdown(struct pci_dev *pdev)
{
- e100_suspend(pdev, PMSG_SUSPEND);
+ bool wake;
+ __e100_shutdown(pdev, wake);
+ if (system_state == SYSTEM_POWER_OFF)
+ __e100_power_off(pdev, wake);
}
/* -- PCI Error Recovery infrastructure -- */
Best,
Rafael
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Detected Tx Unit Hang e1000e versions: 0.5.18.3-NAPI and 0.3.3.3-k6 with kernel 2.6.28.9
On Sun, 19 Apr 2009, Andrey Luzgin wrote: We have repeating problems on several servers with different versions of the driver e1000e with kernel 2.6.28.9 (this version because of tproxy is necessary to us). All servers is Intel® Server Systems SR1560SF with one additional NIC 82572EI Gigabit Ethernet Controller. Enabled ioatdma. This is last log from server with e1000e version: 0.5.18.3-NAPI Apr 19 21:03:47 R2PX1 [188890.816082] :06:00.0: eth1: Detected Tx Unit Hang: Apr 19 21:03:47 R2PX1 [188890.816083] TDH a39 Apr 19 21:03:47 R2PX1 [188890.816084] TDT a25 Apr 19 21:03:47 R2PX1 [188890.816085] next_to_use a25 Apr 19 21:03:47 R2PX1 [188890.816086] next_to_cleana38 Apr 19 21:03:47 R2PX1 [188890.816086] buffer_info[next_to_clean]: Apr 19 21:03:47 R2PX1 [188890.816087] time_stamp 102cf691d Apr 19 21:03:47 R2PX1 [188890.816088] next_to_watcha3b Apr 19 21:03:47 R2PX1 [188890.816088] jiffies 102cf6ab8 Apr 19 21:03:47 R2PX1 [188890.816089] next_to_watch.status 0 Apr 19 21:03:49 R2PX1 [188892.816132] :06:00.0: eth1: Detected Tx Unit Hang: so is it the 82572EI that is having problems? or the ESB2 ports (LOM)? what kind of traffic are you running? And why do you have the TxDescriptor count set so high? I'm wondering if you're running with the (ill advised) setting that someone once posted to a debian mailing list long ago. Please include dmesg from boot through the network coming up. Also please attach the ethtool -e ethX eeprom dump from any ports that are having tx hangs. Also, please post the BIOS and BMC firmware versions. If you have modified the RxAbsIntDelay or RxIntDelay parameters at load, then you've likely ran into a hardware errata that can be avoided by not modifying those parameters. Apr 19 16:47:37 R2PX3 [272540.768103] :06:00.1: eth2: Detected Tx Unit Hang: Apr 19 16:49:31 R2PX3 [272654.768142] :06:00.1: eth2: Detected Tx Unit Hang: ugh, seems like your data pattern makes the hang repeat every two minutes. Well thats good in that it is at least reproducable. Can you try going back to the default driver settings and see if that makes any difference? -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] ixgbe - high tx_restart_queue
On Mon, 20 Apr 2009, Benzi wrote: Flow control is disabled. okay good. Can you explain please why *decreasing* (and not increasing) the tx ring buffer will help avoiding tx_restart_queue? the memory allocation and number of cachelines/pages being accessed goes from 1 page (at 256 descriptors) to 2 pages (at 512 descriptors) and it seems that the more pages that are accessed by the transmit routine/hardware writeback, the slower things get. Regarding InterruptThrottleRate, do you mean that setting it to higher value may also prevent tx_restart_queue by faster tx ring cleanup? absolutely, having a higher interrupt rate (default is only 4000 ints/second for tx) can significantly increase the number of packets that can be processed per second depending on a lot of factors including packet size and system memory speed. Jesse -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] e1000e: NVM corrupted (kernel 2.6.16.y)
On Mon, 20 Apr 2009, Holger Eitzenberger wrote: e1000e: write protect ICHx NVM to prevent malicious write/erase no, doesn't apply to this hardware, as it is not ICH (integrated LOM) it is a standalone 82571 with an actual discreet eeprom chip per port. to include our modules as well in order to find out who is overwriting memory? it is highly unlikely something is succeeding in writing to the eeprom, however, we do know of some locking issues in the driver that we've been resolving specifically for 82571 and that might somehow be related. Do you refer to these two here, or something different? e1000e: do not ever sleep in interrupt context e1000e: reset swflag after resetting hardware there is a different patch, under internal test currently, we hope to release it soon in a new e1000e driver patch to the kernel once it has completed testing. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
