Re: [E1000-devel] I have a Problem in vf rate limit
One other thing to note is that Tx rate limiting is a cap, not a guarantee that the bandwidth allocation can be provisioned. Other issues, especially the resource allocation to your VMs, but also other matters such as the kernel used in the VMs, the hypervisor, etc. can impact total bandwidth capacity. From looking at the results you've shown none of the VMs are exceeding their rate limit. It's impossible for us to tell from your email why you're not getting line rate but as I mentioned above there could be many reasons for that. - Greg -Original Message- From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com] Sent: Monday, April 11, 2011 9:04 AM To: 박대영; e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] I have a Problem in vf rate limit How are you measuring bandwidth? -Original Message- From: 박대영 [mailto:likebulle...@gmail.com] Sent: Monday, April 11, 2011 4:49 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] I have a Problem in vf rate limit hello I'm using a Ixgbe 3.3.8. there are new feature vf rate limit. when I use this feature with 3 VM in xen. and rate limit configuration VM 1: 2Gb/s VM 2: 3Gb/s VM 3: 5Gb/s but result is VM 1: 1962Mb/sec VM2: 1910Mb/sec VM3: 3165Mb/sec SUM of bandwidth is only 7Gb/sec. what is problem. -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] CRC stripping on 82598 and 82599
-Original Message- From: Jean-Mickael Guerin [mailto:jean-mickael.gue...@6wind.com] Sent: Thursday, April 07, 2011 12:17 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] CRC stripping on 82598 and 82599 Hello, It seems CRC is not stripped out on 82599, neither on 82598. The ixgbe driver is setting RDRXCTL for 82599, nothing else. From datasheet I found that RDRXCTL.CRCStrip and HLREG0.RXCRCSTRP must be set to the same value. I tested this patch (ixgbe-3.2.10) on 82598: always set IXGBE_HLREG0_RXCRCSTRP, and it CRC is stripped now: --- a/src/ixgbe_main.c +++ b/src/ixgbe_main.c @@ -3439,6 +3439,8 @@ static void ixgbe_set_rx_buffer_len(struct ixgbe_adapter *adapter) hlreg0 = IXGBE_READ_REG(hw, IXGBE_HLREG0); /* set jumbo enable since MHADD.MFS is keeping size locked at max_frame */ hlreg0 |= IXGBE_HLREG0_JUMBOEN; + /* Enable CRC stripping */ + hlreg0 |= IXGBE_HLREG0_RXCRCSTRP; IXGBE_WRITE_REG(hw, IXGBE_HLREG0, hlreg0); I'm going to test on 82599 too. I can't test for other NIC than 82598 and 82599, may a test for (82598 || 82599) should be added. Thanks for the patch. Are you seeing an issue where the CRC is not being stripped, or is the patch just to satisfy the requirement in the datasheet? If you are seeing a problem could you provide the values of the HLREG0 and RDRXCTL? You can use the ethregs tool available for download from e1000.sf.net. A detailed information about your HW would also be helpful such as lspci -vvv and ethtool -e. Thanks, Emil Regards, Jean-Mickael --- --- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA
So far, I have not see tx hang with my setup. Right now, I am installing latest stable kernel from kernel.org (2.6.38.2) and check if I get a repro. Thanks for updating and working with us on this issue. -Tushar -Original Message- From: Björn Stenberg [mailto:bj...@haxx.se] Sent: Tuesday, April 05, 2011 12:15 AM To: Dave, Tushar N Cc: e1000-devel@lists.sourceforge.net; Brandeburg, Jesse Subject: Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA Dave, Tushar N wrote: Sorry for this to taking so long in coming, however I have not been able to reproduced the issue locally in lab. Are you running any tools or application that helps reproducing this problem? How long it takes this issue to occurs? The machine is running a number of network services, but nothing exotic: rsync, svn, git, smtp, imap, ftp, ssh, cvs, http. The vast majority of the traffic (~1 TB/month) is http. I have not seen any correlation between a specific service and the issue occurring. The issue seems to take something like 10-12 hours after reboot to occur. After that it's quite sporadic, sometimes many hours between hangs, sometimes seconds. See earlier in this thread for logs. -- Björn -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA
Bjorn, Also I noticed that you are running debian kernel linux-image-2.6.37-1-amd64. This is an unstable debian kernel. Have you seen the tx hang with latest stable debian release (Squeeze) which has 2.6.32 kernel? -Tushar -Original Message- From: Dave, Tushar N [mailto:tushar.n.d...@intel.com] Sent: Tuesday, April 12, 2011 11:10 AM To: Björn Stenberg Cc: e1000-devel@lists.sourceforge.net; Brandeburg, Jesse Subject: Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA So far, I have not see tx hang with my setup. Right now, I am installing latest stable kernel from kernel.org (2.6.38.2) and check if I get a repro. Thanks for updating and working with us on this issue. -Tushar -Original Message- From: Björn Stenberg [mailto:bj...@haxx.se] Sent: Tuesday, April 05, 2011 12:15 AM To: Dave, Tushar N Cc: e1000-devel@lists.sourceforge.net; Brandeburg, Jesse Subject: Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA Dave, Tushar N wrote: Sorry for this to taking so long in coming, however I have not been able to reproduced the issue locally in lab. Are you running any tools or application that helps reproducing this problem? How long it takes this issue to occurs? The machine is running a number of network services, but nothing exotic: rsync, svn, git, smtp, imap, ftp, ssh, cvs, http. The vast majority of the traffic (~1 TB/month) is http. I have not seen any correlation between a specific service and the issue occurring. The issue seems to take something like 10-12 hours after reboot to occur. After that it's quite sporadic, sometimes many hours between hangs, sometimes seconds. See earlier in this thread for logs. -- Björn -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH] driver/e1000e: Fix default interrupt mode select
From: Prabhakar Kushwaha prabha...@freescale.com Date: Tue, 12 Apr 2011 10:26:03 +0530 From: Prabhakar prabha...@freescale.com The Intel e1000 device driver defaults to MSI interrupt mode, even if MSI support is not enabled Signed-off-by: Jin Qing b24...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master) added netdev mail-list and e1000 mail-list maintainer Intel folks, you got this? -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA
Dave, Tushar N wrote: Also I noticed that you are running debian kernel linux-image-2.6.37-1-amd64. This is an unstable debian kernel. Have you seen the tx hang with latest stable debian release (Squeeze) which has 2.6.32 kernel? Yes I have. I normally run the 'testing' kernel on this machine. I only upgraded to the unstable kernel because I saw the subject patch and hoped it would help my system too. So far, I have not see tx hang with my setup. Do you want to trade? :-) I have uploaded a new log for your viewing pleasure, with debug data from 352 hangs over the past week: http://bjorn.haxx.se/e1000/kern.log.bz2 Let me know if there is anything else I can do. -- Björn -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA
Björn Stenberg wrote: Yes I have. I normally run the 'testing' kernel on this machine. I only upgraded to the unstable kernel because I saw the subject patch and hoped it would help my system too. I grepped some logs to see how long I've been having this problem, and found IRC discussions mentioning it in september 2009. If I'm reading Debian release notes right, at that time I was most likely running 2.6.30. It is perhaps also worth noting that this machine moved to a different datacenter in the spring of 2010. So it got the same issues in two different network environments (different sites, different ISPs). -- Björn -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] [PATCH] ixgbe: Remove not used blink_led_start/stop code
There is no user for those code.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
drivers/net/ixgbe/ixgbe_82598.c |2 -
drivers/net/ixgbe/ixgbe_82599.c |2 -
drivers/net/ixgbe/ixgbe_common.c | 56 ---
drivers/net/ixgbe/ixgbe_common.h |2 -
drivers/net/ixgbe/ixgbe_type.h |2 -
drivers/net/ixgbe/ixgbe_x540.c |2 -
6 files changed, 66 deletions(-)
Index: linux-2.6/drivers/net/ixgbe/ixgbe_82598.c
===
--- linux-2.6.orig/drivers/net/ixgbe/ixgbe_82598.c
+++ linux-2.6/drivers/net/ixgbe/ixgbe_82598.c
@@ -1207,8 +1207,6 @@ static struct ixgbe_mac_operations mac_o
.get_link_capabilities = ixgbe_get_link_capabilities_82598,
.led_on = ixgbe_led_on_generic,
.led_off= ixgbe_led_off_generic,
- .blink_led_start= ixgbe_blink_led_start_generic,
- .blink_led_stop = ixgbe_blink_led_stop_generic,
.set_rar= ixgbe_set_rar_generic,
.clear_rar = ixgbe_clear_rar_generic,
.set_vmdq = ixgbe_set_vmdq_82598,
Index: linux-2.6/drivers/net/ixgbe/ixgbe_82599.c
===
--- linux-2.6.orig/drivers/net/ixgbe/ixgbe_82599.c
+++ linux-2.6/drivers/net/ixgbe/ixgbe_82599.c
@@ -2052,8 +2052,6 @@ static struct ixgbe_mac_operations mac_o
.get_link_capabilities = ixgbe_get_link_capabilities_82599,
.led_on = ixgbe_led_on_generic,
.led_off= ixgbe_led_off_generic,
- .blink_led_start= ixgbe_blink_led_start_generic,
- .blink_led_stop = ixgbe_blink_led_stop_generic,
.set_rar= ixgbe_set_rar_generic,
.clear_rar = ixgbe_clear_rar_generic,
.set_vmdq = ixgbe_set_vmdq_generic,
Index: linux-2.6/drivers/net/ixgbe/ixgbe_common.c
===
--- linux-2.6.orig/drivers/net/ixgbe/ixgbe_common.c
+++ linux-2.6/drivers/net/ixgbe/ixgbe_common.c
@@ -2242,62 +2242,6 @@ s32 ixgbe_enable_rx_dma_generic(struct i
}
/**
- * ixgbe_blink_led_start_generic - Blink LED based on index.
- * @hw: pointer to hardware structure
- * @index: led number to blink
- **/
-s32 ixgbe_blink_led_start_generic(struct ixgbe_hw *hw, u32 index)
-{
- ixgbe_link_speed speed = 0;
- bool link_up = 0;
- u32 autoc_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC);
- u32 led_reg = IXGBE_READ_REG(hw, IXGBE_LEDCTL);
-
- /*
-* Link must be up to auto-blink the LEDs;
-* Force it if link is down.
-*/
- hw-mac.ops.check_link(hw, speed, link_up, false);
-
- if (!link_up) {
- autoc_reg |= IXGBE_AUTOC_AN_RESTART;
- autoc_reg |= IXGBE_AUTOC_FLU;
- IXGBE_WRITE_REG(hw, IXGBE_AUTOC, autoc_reg);
- msleep(10);
- }
-
- led_reg = ~IXGBE_LED_MODE_MASK(index);
- led_reg |= IXGBE_LED_BLINK(index);
- IXGBE_WRITE_REG(hw, IXGBE_LEDCTL, led_reg);
- IXGBE_WRITE_FLUSH(hw);
-
- return 0;
-}
-
-/**
- * ixgbe_blink_led_stop_generic - Stop blinking LED based on index.
- * @hw: pointer to hardware structure
- * @index: led number to stop blinking
- **/
-s32 ixgbe_blink_led_stop_generic(struct ixgbe_hw *hw, u32 index)
-{
- u32 autoc_reg = IXGBE_READ_REG(hw, IXGBE_AUTOC);
- u32 led_reg = IXGBE_READ_REG(hw, IXGBE_LEDCTL);
-
- autoc_reg = ~IXGBE_AUTOC_FLU;
- autoc_reg |= IXGBE_AUTOC_AN_RESTART;
- IXGBE_WRITE_REG(hw, IXGBE_AUTOC, autoc_reg);
-
- led_reg = ~IXGBE_LED_MODE_MASK(index);
- led_reg = ~IXGBE_LED_BLINK(index);
- led_reg |= IXGBE_LED_LINK_ACTIVE IXGBE_LED_MODE_SHIFT(index);
- IXGBE_WRITE_REG(hw, IXGBE_LEDCTL, led_reg);
- IXGBE_WRITE_FLUSH(hw);
-
- return 0;
-}
-
-/**
* ixgbe_get_san_mac_addr_offset - Get SAN MAC address offset from the EEPROM
* @hw: pointer to hardware structure
* @san_mac_offset: SAN MAC address offset
Index: linux-2.6/drivers/net/ixgbe/ixgbe_common.h
===
--- linux-2.6.orig/drivers/net/ixgbe/ixgbe_common.h
+++ linux-2.6/drivers/net/ixgbe/ixgbe_common.h
@@ -85,8 +85,6 @@ s32 ixgbe_check_mac_link_generic(struct
bool *link_up, bool link_up_wait_to_complete);
s32 ixgbe_get_wwn_prefix_generic(struct ixgbe_hw *hw, u16 *wwnn_prefix,
u16 *wwpn_prefix);
-s32 ixgbe_blink_led_start_generic(struct ixgbe_hw *hw, u32 index);
-s32 ixgbe_blink_led_stop_generic(struct ixgbe_hw *hw, u32 index);
void ixgbe_set_mac_anti_spoofing(struct ixgbe_hw *hw, bool enable, int pf);
void ixgbe_set_vlan_anti_spoofing(struct ixgbe_hw *hw, bool enable, int vf);
Index: linux-2.6/drivers/net/ixgbe/ixgbe_type.h
