All of lore.kernel.org
 help / color / mirror / Atom feed
* Solved: Re: ixgbe/linux/sparc perf issues
@ 2015-01-09 15:21 Sowmini Varadhan
  2015-01-13  1:08 ` [linux-nics] " Tantilov, Emil S
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Sowmini Varadhan @ 2015-01-09 15:21 UTC (permalink / raw)
  To: sparclinux


> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Thu, 11 Dec 2014 14:45:42 -0500
> I'm looking at an iperf issue running over ixgbe on linux
> on a sparc T5-2 platform (64 cpu) where we cannot get to line-speed
> (peaks at 3 Gbps on a 10Gbps link) and I'm trying to get to the bottom
> of this.

On (12/11/14 15:09), David Miller replied:
davem> The real overhead is unavoidable due to the way the hypervisor access
davem> to the IOMMU is implemented in sun4v.
       :
davem> I've known about this issue for a decade and I do not think there is
davem> anything we can really do about this.

Not so.

The HV implementation can handle 1 (maybe even 2) NIC ports per
socket on a T5-2 without needing any additional DMA optimizations.

The real problem is that the ixgbe driver (and probably a few other
related drivers?) turns off relaxed-ordering during startup (not
sure why) and never turns it back on.

The absence of relaxed-ordering is a serous serialization point,
and is responsible for throttling throughput down to 3 Gbps.

After I hack things as shown in the patch below, I am able to easily
get 9-9.5 Gbps. (The only other patch needed is the iommu lock-break-up:
http://www.spinics.net/lists/sparclinux/msg13238.html)

Perhaps someone in e1000-devel/linux.nics can provide some background 
here on when this really needs to be turned off, and where to turn it back 
on cleanly.

I'm sure there are more drivers than ixgbe that have this crippling bug. 

there is another oddity that 'lspci -vv' reports RlxOrd as enabled,
even though this is clearly not the case, but that's a secondary issue.

--Sowmini

-----------patch follows below ---------------------------------------------


diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9c66bab..4453d92 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -338,6 +338,26 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
 	return 0;
 }
 
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw)
+{
+	u32 i;
+	u32 regval;
+
+	/* Enable relaxed ordering */
+	for (i = 0; i < hw->mac.max_tx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
+		regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
+	}
+
+	for (i = 0; i < hw->mac.max_rx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+		regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+			    IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+	}
+}
+
 /**
  *  ixgbe_init_hw_generic - Generic hardware initialization
  *  @hw: pointer to hardware structure
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 8cfadcb..c399c18 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -37,6 +37,7 @@ s32 ixgbe_init_ops_generic(struct ixgbe_hw *hw);
 s32 ixgbe_init_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw);
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw);
 s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw);
 s32 ixgbe_read_pba_string_generic(struct ixgbe_hw *hw, u8 *pba_num,
 				  u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..e97c89c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4898,6 +4898,7 @@ void ixgbe_reset(struct ixgbe_adapter *adapter)
 
 	if (test_bit(__IXGBE_PTP_RUNNING, &adapter->state))
 		ixgbe_ptp_reset(adapter);
+	ixgbe_enable_relaxed_ordering(hw);
 }
 
 /**
@@ -8470,6 +8471,7 @@ skip_sriov:
 			   "representative who provided you with this "
 			   "hardware.\n");
 	}
+	ixgbe_enable_relaxed_ordering(hw);
 	strcpy(netdev->name, "eth%d");
 	err = register_netdev(netdev);
 	if (err)


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* RE: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
  2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
@ 2015-01-13  1:08 ` Tantilov, Emil S
  2015-01-13  1:24 ` Sowmini Varadhan
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Tantilov, Emil S @ 2015-01-13  1:08 UTC (permalink / raw)
  To: sparclinux

>-----Original Message-----
>From: linux-nics-bounces@isotope.jf.intel.com [mailto:linux-nics-bounces@isotope.jf.intel.com] On Behalf Of >Sowmini Varadhan
>Sent: Friday, January 09, 2015 7:21 AM
>To: David Miller
>Cc: e1000-devel@lists.sourceforge.net; sparclinux@vger.kernel.org; Linux NICS
>Subject: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
>> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>> Date: Thu, 11 Dec 2014 14:45:42 -0500
>> I'm looking at an iperf issue running over ixgbe on linux
>> on a sparc T5-2 platform (64 cpu) where we cannot get to line-speed
>> (peaks at 3 Gbps on a 10Gbps link) and I'm trying to get to the bottom
>> of this.
>
>On (12/11/14 15:09), David Miller replied:
>davem> The real overhead is unavoidable due to the way the hypervisor access
>davem> to the IOMMU is implemented in sun4v.
>       :
>davem> I've known about this issue for a decade and I do not think there is
>davem> anything we can really do about this.
>
>Not so.
>
>The HV implementation can handle 1 (maybe even 2) NIC ports per
>socket on a T5-2 without needing any additional DMA optimizations.
>
>The real problem is that the ixgbe driver (and probably a few other
>related drivers?) turns off relaxed-ordering during startup (not
>sure why) and never turns it back on.

Relaxed ordering is disabled by default at init and the driver only enables it for reads when DCA is used, which I suppose is not the case for you since you are on sparc.

>The absence of relaxed-ordering is a serous serialization point,
>and is responsible for throttling throughput down to 3 Gbps.
>
>After I hack things as shown in the patch below, I am able to easily
>get 9-9.5 Gbps. (The only other patch needed is the iommu lock-break-up:
>http://www.spinics.net/lists/sparclinux/msg13238.html)
>
>Perhaps someone in e1000-devel/linux.nics can provide some background 
>here on when this really needs to be turned off, and where to turn it back 
>on cleanly.

Relaxed ordering was disabled due to an issue with some chipsets. There is a comment to that effect when enabling relaxed ordering for reads in ixgbe_update_tx_dca(). This was done back in 2011, so I'm still trying to dig through the details.

>I'm sure there are more drivers than ixgbe that have this crippling bug.

As I mentioned above it is intentional. I guess it makes sense to have it enabled for chipsets where it helps with performance, but I'm not sure what the criteria should be. In your patch below you enable relaxed ordering for writes - have you tested if there is any effect if you enable it only for reads or both?

>there is another oddity that 'lspci -vv' reports RlxOrd as enabled,
>even though this is clearly not the case, but that's a secondary issue.

According to the docs - the IXGBE_DCA registers control R/W relaxed ordering per-queue. There is another register (IXGBE_CTRL_EXT - 0x018) that seems to enable/disable relaxed ordering for the device which could be why you are seeing the RlxOrd bit set, although I can't be sure.

Thanks,
Emil


--Sowmini

-----------patch follows below ---------------------------------------------


diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9c66bab..4453d92 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -338,6 +338,26 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
 	return 0;
 }
 
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw)
+{
+	u32 i;
+	u32 regval;
+
+	/* Enable relaxed ordering */
+	for (i = 0; i < hw->mac.max_tx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
+		regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
+	}
+
+	for (i = 0; i < hw->mac.max_rx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+		regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+			    IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+	}
+}
+
 /**
  *  ixgbe_init_hw_generic - Generic hardware initialization
  *  @hw: pointer to hardware structure
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 8cfadcb..c399c18 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -37,6 +37,7 @@ s32 ixgbe_init_ops_generic(struct ixgbe_hw *hw);
 s32 ixgbe_init_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw);
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw);
 s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw);
 s32 ixgbe_read_pba_string_generic(struct ixgbe_hw *hw, u8 *pba_num,
 				  u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..e97c89c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4898,6 +4898,7 @@ void ixgbe_reset(struct ixgbe_adapter *adapter)
 
 	if (test_bit(__IXGBE_PTP_RUNNING, &adapter->state))
 		ixgbe_ptp_reset(adapter);
+	ixgbe_enable_relaxed_ordering(hw);
 }
 
 /**
@@ -8470,6 +8471,7 @@ skip_sriov:
 			   "representative who provided you with this "
 			   "hardware.\n");
 	}
+	ixgbe_enable_relaxed_ordering(hw);
 	strcpy(netdev->name, "eth%d");
 	err = register_netdev(netdev);
 	if (err)

_______________________________________________
Linux-nics mailing list
Linux-nics@intel.com

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
  2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
  2015-01-13  1:08 ` [linux-nics] " Tantilov, Emil S
@ 2015-01-13  1:24 ` Sowmini Varadhan
  2015-01-13 15:45 ` Sowmini Varadhan
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Sowmini Varadhan @ 2015-01-13  1:24 UTC (permalink / raw)
  To: sparclinux

On (01/13/15 01:08), Tantilov, Emil S wrote:
>
> Relaxed ordering is disabled by default at init and the driver only
> enables it for reads when DCA is used, which I suppose is not the case
> for you since you are on sparc.
   :
> Relaxed ordering was disabled due to an issue with some chipsets. There
> is a comment to that effect when enabling relaxed ordering for reads in
> ixgbe_update_tx_dca(). This was done back in 2011, so I'm still trying
> to dig through the details.

> As I mentioned above it is intentional. I guess it makes sense to
> have it enabled for chipsets where it helps with performance, but I'm
> not sure what the criteria should be. In your patch below you enable
> relaxed ordering for writes - have you tested if there is any effect if
> you enable it only for reads or both?

I'm not sure how to instrument reads separately from writes?
In my case (tested with iperf, 10 threads) I'm guessing both happen 
at some point. But the effect of the absence of RO is seen most clearly
for iperf acting as the Rx (i.e., lot of incoming TCP traffic from a
remote host, relatively little outgoing TCP traffic).

FWIW,  I based my patch on the equivalent solaris driver code, which has
an indirection per chipset, resulting in something like the patch below
(which I'm still testing on sparc/x86 with X540/82598). But the concern
is that we may need this fix in other related drivers like igb- I
havent tested each driver yet.

I think the perf throttle might not be seen on x86 because of DCA
and other enhancements that are not available on sparc? 

-----------------------------------------------------------------------

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index c5c97b4..85c7a28 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1161,6 +1161,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
 	.clear_hw_cntrs		= &ixgbe_clear_hw_cntrs_generic,
 	.get_media_type		= &ixgbe_get_media_type_82598,
 	.enable_rx_dma          = &ixgbe_enable_rx_dma_generic,
+	.enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering,
 	.get_mac_addr		= &ixgbe_get_mac_addr_generic,
 	.stop_adapter		= &ixgbe_stop_adapter_generic,
 	.get_bus_info           = &ixgbe_get_bus_info_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 9c66bab..4453d92 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -338,6 +338,26 @@ s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw)
 	return 0;
 }
 
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw)
+{
+	u32 i;
+	u32 regval;
+
+	/* Enable relaxed ordering */
+	for (i = 0; i < hw->mac.max_tx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_TXCTRL_82599(i));
+		regval |= IXGBE_DCA_TXCTRL_DESC_WRO_EN;
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_TXCTRL_82599(i), regval);
+	}
+
+	for (i = 0; i < hw->mac.max_rx_queues; i++) {
+		regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
+		regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
+			    IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
+		IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
+	}
+}
+
 /**
  *  ixgbe_init_hw_generic - Generic hardware initialization
  *  @hw: pointer to hardware structure
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
index 8cfadcb..c399c18 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
@@ -37,6 +37,7 @@ s32 ixgbe_init_ops_generic(struct ixgbe_hw *hw);
 s32 ixgbe_init_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_generic(struct ixgbe_hw *hw);
 s32 ixgbe_start_hw_gen2(struct ixgbe_hw *hw);
+void ixgbe_enable_relaxed_ordering(struct ixgbe_hw *hw);
 s32 ixgbe_clear_hw_cntrs_generic(struct ixgbe_hw *hw);
 s32 ixgbe_read_pba_string_generic(struct ixgbe_hw *hw, u8 *pba_num,
 				  u32 pba_num_size);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 2ed2c7d..a35a264 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4898,6 +4898,9 @@ void ixgbe_reset(struct ixgbe_adapter *adapter)
 
 	if (test_bit(__IXGBE_PTP_RUNNING, &adapter->state))
 		ixgbe_ptp_reset(adapter);
+
+	if (hw->mac.ops.enable_relaxed_ordering)
+		hw->mac.ops.enable_relaxed_ordering(hw);
 }
 
 /**
@@ -8470,6 +8473,8 @@ skip_sriov:
 			   "representative who provided you with this "
 			   "hardware.\n");
 	}
+	if (hw->mac.ops.enable_relaxed_ordering)
+		hw->mac.ops.enable_relaxed_ordering(hw);
 	strcpy(netdev->name, "eth%d");
 	err = register_netdev(netdev);
 	if (err)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index d101b25..b967241 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -3013,6 +3013,7 @@ struct ixgbe_mac_operations {
 	void (*release_swfw_sync)(struct ixgbe_hw *, u32);
 	s32 (*prot_autoc_read)(struct ixgbe_hw *, bool *, u32 *);
 	s32 (*prot_autoc_write)(struct ixgbe_hw *, u32, bool);
+	void (*enable_relaxed_ordering)(struct ixgbe_hw *);
 
 	/* Link */
 	void (*disable_tx_laser)(struct ixgbe_hw *);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
index ba54ff0..88adad2 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c
@@ -781,6 +781,7 @@ static struct ixgbe_mac_operations mac_ops_X540 = {
 	.clear_hw_cntrs         = &ixgbe_clear_hw_cntrs_generic,
 	.get_media_type         = &ixgbe_get_media_type_X540,
 	.enable_rx_dma          = &ixgbe_enable_rx_dma_generic,
+	.enable_relaxed_ordering = &ixgbe_enable_relaxed_ordering,
 	.get_mac_addr           = &ixgbe_get_mac_addr_generic,
 	.get_san_mac_addr       = &ixgbe_get_san_mac_addr_generic,
 	.get_device_caps        = &ixgbe_get_device_caps_generic,
-- 
1.7.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
  2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
  2015-01-13  1:08 ` [linux-nics] " Tantilov, Emil S
  2015-01-13  1:24 ` Sowmini Varadhan
@ 2015-01-13 15:45 ` Sowmini Varadhan
  2015-01-13 21:58 ` David Miller
  2015-01-13 22:00 ` Sowmini Varadhan
  4 siblings, 0 replies; 6+ messages in thread
From: Sowmini Varadhan @ 2015-01-13 15:45 UTC (permalink / raw)
  To: sparclinux

On (01/13/15 01:08), Tantilov, Emil S wrote:
> Relaxed ordering was disabled due to an issue with some chipsets. There
> is a comment to that effect when enabling relaxed ordering for reads in
> ixgbe_update_tx_dca(). This was done back in 2011, so I'm still trying
> to dig through the details.

It would be helpful to know exactly which chipsets, so that in
those cases, we can set the ->enable_relaxed_ordering in my patch
to null (or make this setting specific to CONFIG_SPARC?)

> ... In your patch below you enable
> relaxed ordering for writes - have you tested if there is any effect if
> you enable it only for reads or both?

The critical loop is the one for Rx, namely, to re-enable this:

        for (i = 0; i < hw->mac.max_rx_queues; i++) {
                regval = IXGBE_READ_REG(hw, IXGBE_DCA_RXCTRL(i));
                regval |= (IXGBE_DCA_RXCTRL_DATA_WRO_EN |
                            IXGBE_DCA_RXCTRL_HEAD_WRO_EN);
                IXGBE_WRITE_REG(hw, IXGBE_DCA_RXCTRL(i), regval);
	}

fwiw, I tested/verified the patch on sparc/X540 and (more light testing) 
on x86/82598.

So knowing the history here on the 2011 specifics (that you mention
above) would be useful, then we can discuss how to tailor the fix and
which other drivers also need something similar.

--Sowmini


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
  2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
                   ` (2 preceding siblings ...)
  2015-01-13 15:45 ` Sowmini Varadhan
@ 2015-01-13 21:58 ` David Miller
  2015-01-13 22:00 ` Sowmini Varadhan
  4 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2015-01-13 21:58 UTC (permalink / raw)
  To: sparclinux

From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 13 Jan 2015 10:45:30 -0500

> On (01/13/15 01:08), Tantilov, Emil S wrote:
>> Relaxed ordering was disabled due to an issue with some chipsets. There
>> is a comment to that effect when enabling relaxed ordering for reads in
>> ixgbe_update_tx_dca(). This was done back in 2011, so I'm still trying
>> to dig through the details.
> 
> It would be helpful to know exactly which chipsets, so that in
> those cases, we can set the ->enable_relaxed_ordering in my patch
> to null (or make this setting specific to CONFIG_SPARC?)

I think they are talking about "system chipsets", ie. relaxed ordering
doesn't work reliably on this or that AMD/Intel/whatever system
chipset.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [linux-nics] Solved: Re: ixgbe/linux/sparc perf issues
  2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
                   ` (3 preceding siblings ...)
  2015-01-13 21:58 ` David Miller
@ 2015-01-13 22:00 ` Sowmini Varadhan
  4 siblings, 0 replies; 6+ messages in thread
From: Sowmini Varadhan @ 2015-01-13 22:00 UTC (permalink / raw)
  To: sparclinux

On (01/13/15 16:58), David Miller wrote:
> From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Date: Tue, 13 Jan 2015 10:45:30 -0500
> 
> > On (01/13/15 01:08), Tantilov, Emil S wrote:
> >> Relaxed ordering was disabled due to an issue with some chipsets. There
> >> is a comment to that effect when enabling relaxed ordering for reads in
> >> ixgbe_update_tx_dca(). This was done back in 2011, so I'm still trying
> >> to dig through the details.
> > 
> > It would be helpful to know exactly which chipsets, so that in
> > those cases, we can set the ->enable_relaxed_ordering in my patch
> > to null (or make this setting specific to CONFIG_SPARC?)
> 
> I think they are talking about "system chipsets", ie. relaxed ordering
> doesn't work reliably on this or that AMD/Intel/whatever system
> chipset.

If that's what they have in mind (as opposed to some specific
set of ethernet controller) then we can #ifdef CONFIG_SPARC the
->enable_relaxed_ordering initialization?

--Sowmini


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-01-13 22:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-09 15:21 Solved: Re: ixgbe/linux/sparc perf issues Sowmini Varadhan
2015-01-13  1:08 ` [linux-nics] " Tantilov, Emil S
2015-01-13  1:24 ` Sowmini Varadhan
2015-01-13 15:45 ` Sowmini Varadhan
2015-01-13 21:58 ` David Miller
2015-01-13 22:00 ` Sowmini Varadhan

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.