[net-next 0/8][pull request] 10GbE Intel Wired LAN Driver Updates 2016-01-08

[net-next 0/8][pull request] 10GbE Intel Wired LAN Driver Updates 2016-01-08

[Jeff Kirsher]

This series contains updates to ixgbe only.

Vasu provides three fixes for ixgbe, first assigns a minimum credit to
a traffic class to resolve a Tx hang for CEE mode configuration.  Second
fix changes the driver to use netdev->fcoe_ddp_xid instead of our local
IXGBE_FCOE_DDP_MAX, since it is correctly set for our different devices
and avoids a DDP skip error on X550.  Lastly fix the PFC configuration
to include X550 devices.

Emil provides a fix for reporting the speed in ethtool by using the
stored value in out adapter structure.  This is due to external drivers
may end up with unknown speed when calling ethtool_get_settings().

Mark fixes the handling of any outer UDP checksum, by passing the
skb up with CHECKSUM_NONE when an outer UDP checksum is set.  This
will cause the stack to check the checksum, also do not increment an
error counter because we do not really know if there is an actual error.
Ixgbe ATR was not handling IPv6 extended headers, so ATR is not being
performed on such packets.  Fix this by skipping extended headers
when they are present.

Usha fixes an issue with X550 and getting FDMI HBA attributes when
FCoE support is enabled.

Neerav fixes an issue for X550 when FCoE and SR-IOV are enabled, which
the hardware generates MDD events.  Resolve this by setting the expected
values in the transmit context descriptors for FCoE/FIP frames and
adding a flush after writing the RDLEN register.

The following are changes since commit 24759daa018f0fc8cccebc89d3dee0953e73785a:
  Merge branch 'macb-usrio-cap'
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 10GbE

Emil Tantilov (1):
  ixgbe: do not call check_link for ethtool in ixgbe_get_settings()

Mark Rustad (2):
  ixgbe: Correct handling of any outer UDP checksum setting
  ixgbe: Make ATR recognize IPv6 extended headers

Neerav Parikh (1):
  ixgbe: Fix MDD events generated when FCoE+SRIOV are enabled

Usha Ketineni (1):
  ixgbe: Fix to get FDMI HBA attributes information with X550

Vasu Dev (3):
  ixgbe: Fill at least min credits to a TC credit refills
  ixgbe: use correct FCoE DDP max check
  ixgbe: fix broken PFC with X550

 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c       |  7 ++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c |  6 +--
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c   |  7 +--
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c      | 16 ++++---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c      | 52 +++++++++++++++++-----
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h      |  1 +
 6 files changed, 64 insertions(+), 25 deletions(-)

-- 
2.5.0

[net-next 1/8] ixgbe: Fill at least min credits to a TC credit refills

[Jeff Kirsher]

From: Vasu Dev <vasu.dev@intel.com>

Currently credit_refill and credit_max could be zero for a TC and that
is causing Tx hang for CEE mode configuration, so to fix that have at
min credit assigned to a TC and that is as what IEEE mode already does.

Change-ID: If652c133093a21e530f4e9eab09097976f57fb12
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
index a507a6f..02c7333 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb.c
@@ -139,6 +139,11 @@ s32 ixgbe_dcb_calculate_tc_credits(struct ixgbe_hw *hw,
 		/* Calculate credit refill ratio using multiplier */
 		credit_refill = min(link_percentage * min_multiplier,
 				    MAX_CREDIT_REFILL);
+
+		/* Refill at least minimum credit */
+		if (credit_refill < min_credit)
+			credit_refill = min_credit;
+
 		p->data_credits_refill = (u16)credit_refill;
 
 		/* Calculate maximum credit for the TC */
@@ -149,7 +154,7 @@ s32 ixgbe_dcb_calculate_tc_credits(struct ixgbe_hw *hw,
 		 * of a TC is too small, the maximum credit may not be
 		 * enough to send out a jumbo frame in data plane arbitration.
 		 */
-		if (credit_max && (credit_max < min_credit))
+		if (credit_max < min_credit)
 			credit_max = min_credit;
 
 		if (direction == DCB_TX_CONFIG) {
-- 
2.5.0

[net-next 2/8] ixgbe: use correct FCoE DDP max check

[Jeff Kirsher]

From: Vasu Dev <vasu.dev@intel.com>

Use fcoe_ddp_xid from netdev as this is correctly set for different
device IDs to avoid DDP skip error on X550 as "xid=0x20b out-of-range"

Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index 5f98870..5982937 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -77,7 +77,7 @@ int ixgbe_fcoe_ddp_put(struct net_device *netdev, u16 xid)
 	if (!netdev)
 		return 0;
 
-	if (xid >= IXGBE_FCOE_DDP_MAX)
+	if (xid >= netdev->fcoe_ddp_xid)
 		return 0;
 
 	adapter = netdev_priv(netdev);
@@ -177,7 +177,7 @@ static int ixgbe_fcoe_ddp_setup(struct net_device *netdev, u16 xid,
 		return 0;
 
 	adapter = netdev_priv(netdev);
-	if (xid >= IXGBE_FCOE_DDP_MAX) {
+	if (xid >= netdev->fcoe_ddp_xid) {
 		e_warn(drv, "xid=0x%x out-of-range\n", xid);
 		return 0;
 	}
-- 
2.5.0

[net-next 3/8] ixgbe: fix broken PFC with X550

[Jeff Kirsher]

From: Vasu Dev <vasu.dev@intel.com>

PFC is configuration is skipped for X550 devices due to a incorrect
device id check, fixing that to include X550 PFC configuration.

Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
index 23277ab..b5cc989 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_dcb_82599.c
@@ -223,13 +223,13 @@ s32 ixgbe_dcb_config_pfc_82599(struct ixgbe_hw *hw, u8 pfc_en, u8 *prio_tc)
 	reg |= IXGBE_MFLCN_DPF;
 
 	/*
-	 * X540 supports per TC Rx priority flow control.  So
-	 * clear all TCs and only enable those that should be
+	 * X540 & X550 supports per TC Rx priority flow control.
+	 * So clear all TCs and only enable those that should be
 	 * enabled.
 	 */
 	reg &= ~(IXGBE_MFLCN_RPFCE_MASK | IXGBE_MFLCN_RFCE);
 
-	if (hw->mac.type == ixgbe_mac_X540)
+	if (hw->mac.type >= ixgbe_mac_X540)
 		reg |= pfc_en << IXGBE_MFLCN_RPFCE_SHIFT;
 
 	if (pfc_en)
-- 
2.5.0

[net-next 4/8] ixgbe: do not call check_link for ethtool in ixgbe_get_settings()

[Jeff Kirsher]

From: Emil Tantilov <emil.s.tantilov@intel.com>

In ixgbe_get_settings() the link status and speed of the interface
are determined based on a read from the LINKS register via the call
to mac.ops.check.link(). This can cause issues where external drivers
may end up with unknown speed when calling ethtool_get_settings().

Instead of calling the mac.ops.check_link() we can report the speed
from the adapter structure which is populated by the driver.

Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 2448eba..bea96b3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -185,9 +185,7 @@ static int ixgbe_get_settings(struct net_device *netdev,
 	struct ixgbe_adapter *adapter = netdev_priv(netdev);
 	struct ixgbe_hw *hw = &adapter->hw;
 	ixgbe_link_speed supported_link;
-	u32 link_speed = 0;
 	bool autoneg = false;
-	bool link_up;
 
 	hw->mac.ops.get_link_capabilities(hw, &supported_link, &autoneg);
 
@@ -313,9 +311,8 @@ static int ixgbe_get_settings(struct net_device *netdev,
 		break;
 	}
 
-	hw->mac.ops.check_link(hw, &link_speed, &link_up, false);
-	if (link_up) {
-		switch (link_speed) {
+	if (netif_carrier_ok(netdev)) {
+		switch (adapter->link_speed) {
 		case IXGBE_LINK_SPEED_10GB_FULL:
 			ethtool_cmd_speed_set(ecmd, SPEED_10000);
 			break;
-- 
2.5.0

ixgbe: get link speed as a slave nic unrelated with link

[zyjzyj2000]

Hi, Emil

Thanks for your patch.
After I applied your patch, the following are the feedback from my users.

"
Users had tested the latest patch that you provided and it is much improved now. However it’s still not good enough as the users are planning field deployment. Here are their findings:

So close, but not quite 100%. I did run over 2500 re-negotiations on one interface of a bonded pair and got the 0 MBps status total of three times. The longest run without single error was something like 1800 re-negotiations or so. So, this version seems to improve the situation immensely (the unpatched driver fails like 25% of the time), but there still seems to remain some tiny race somewhere.

So  it seems the failure occurs once every 600-900 connections.
"

I delved into the source code. And I found that maybe this time slice can result in this problem.

bonding                ixgbe 
  |                     |
  |                    carrier_on
  |                     |
  |    <----------------|
 link_up                |
  |                     |
  |                    carrier_off
  |                     |
 get_link_speed ------->|
  |                     |

Now bonding driver is link up while speed is link_speed_unknown because of link flap.

To an independent nic, it is meaningless to get link speed while carrier is off. But to a slave nic, maybe it is helpful, especially nic link flaps.

Maybe this patch can fix the above time slice.

Any reply is appreciated.

Best Regards!
Zhu Yanjun

[PATCH 1/1] ixgbe: get link speed as a slave nic unrelated with link up

[zyjzyj2000]

From: Zhu Yanjun <zyjzyj2000@gmail.com>

The commit 0e4d422f5f72 ("ixgbe: do not call check_link for ethtool
in ixgbe_get_settings()") decreases the bonding failures. But the
following time slice still results in a bonding failure.

bonding                ixgbe
  |                     |
  |                    carrier_on
  |                     |
  |    <----------------|
 link_up                |
  |                     |
  |                    carrier_off
  |                     |
 get_link_speed ------->|
  |                     |

As such, the nic link speed can unconditionally be gotten as a
slave nic whether the link is up or not.

Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index bea96b3..53edf39 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -311,7 +311,7 @@ static int ixgbe_get_settings(struct net_device *netdev,
 		break;
 	}
 
-	if (netif_carrier_ok(netdev)) {
+	if (netif_carrier_ok(netdev) || (netdev->flags & IFF_SLAVE)) {
 		switch (adapter->link_speed) {
 		case IXGBE_LINK_SPEED_10GB_FULL:
 			ethtool_cmd_speed_set(ecmd, SPEED_10000);
-- 
1.7.9.5

RE: [PATCH 1/1] ixgbe: get link speed as a slave nic unrelated with link up

[Tantilov, Emil S]

>-----Original Message-----
>From: zyjzyj2000@gmail.com [mailto:zyjzyj2000@gmail.com]
>Sent: Sunday, January 31, 2016 11:28 PM
>To: zyjzyj2000@gmail.com; Tantilov, Emil S; Schmitt, Phillip J; Kirsher,
>Jeffrey T; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
>Shteinbock, Boris (Wind River)
>Subject: [PATCH 1/1] ixgbe: get link speed as a slave nic unrelated with
>link up
>
>From: Zhu Yanjun <zyjzyj2000@gmail.com>
>
>The commit 0e4d422f5f72 ("ixgbe: do not call check_link for ethtool
>in ixgbe_get_settings()") decreases the bonding failures. But the
>following time slice still results in a bonding failure.
>
>bonding                ixgbe
>  |                     |
>  |                    carrier_on
>  |                     |
>  |    <----------------|
> link_up                |
>  |                     |
>  |                    carrier_off
>  |                     |
> get_link_speed ------->|
>  |                     |

The driver does not set carrier_off unless the link is actually down.

Did you actually test this patch?

Thanks,
Emil

RE: ixgbe: get link speed as a slave nic unrelated with link

[Tantilov, Emil S]

>-----Original Message-----
>From: zyjzyj2000@gmail.com [mailto:zyjzyj2000@gmail.com]
>Sent: Sunday, January 31, 2016 11:28 PM
>To: zyjzyj2000@gmail.com; Tantilov, Emil S; Schmitt, Phillip J; Kirsher,
>Jeffrey T; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
>Shteinbock, Boris (Wind River)
>Subject: ixgbe: get link speed as a slave nic unrelated with link
>
>
>Hi, Emil
>
>Thanks for your patch.
>After I applied your patch, the following are the feedback from my users.
>
>"
>Users had tested the latest patch that you provided and it is much improved
>now. However it’s still not good enough as the users are planning field
>deployment. Here are their findings:
>
>So close, but not quite 100%. I did run over 2500 re-negotiations on one
>interface of a bonded pair and got the 0 MBps status total of three times.
>The longest run without single error was something like 1800 re-
>negotiations or so. So, this version seems to improve the situation
>immensely (the unpatched driver fails like 25% of the time), but there
>still seems to remain some tiny race somewhere.

Yes at the time of the bonding interface coming up there can be a message about 0 Mbps in dmesg,
however the actual bond once fully up will have the correct speeds as seen by:
#cat /proc/net/bonding/bond0

Thanks,
Emil

Re: ixgbe: get link speed as a slave nic unrelated with link

[zhuyj]

Hi, Emil

Thanks for your reply.

I made simple tests. And maybe this patch should work. Because you can
reproduce this problem, would you like to make tests with this patch?

If this patch can fix this problem, it can prove that the root cause is 
correct.
We can find another solution to fix this problem.

If this patch can not fix this problem, maybe we should make further 
investigations
to find the root cause.

Thanks a lot.
Zhu Yanjun

On 02/01/2016 11:53 PM, Tantilov, Emil S wrote:
>> -----Original Message-----
>> From: zyjzyj2000@gmail.com [mailto:zyjzyj2000@gmail.com]
>> Sent: Sunday, January 31, 2016 11:28 PM
>> To: zyjzyj2000@gmail.com; Tantilov, Emil S; Schmitt, Phillip J; Kirsher,
>> Jeffrey T; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
>> Shteinbock, Boris (Wind River)
>> Subject: ixgbe: get link speed as a slave nic unrelated with link
>>
>>
>> Hi, Emil
>>
>> Thanks for your patch.
>> After I applied your patch, the following are the feedback from my users.
>>
>> "
>> Users had tested the latest patch that you provided and it is much improved
>> now. However it’s still not good enough as the users are planning field
>> deployment. Here are their findings:
>>
>> So close, but not quite 100%. I did run over 2500 re-negotiations on one
>> interface of a bonded pair and got the 0 MBps status total of three times.
>> The longest run without single error was something like 1800 re-
>> negotiations or so. So, this version seems to improve the situation
>> immensely (the unpatched driver fails like 25% of the time), but there
>> still seems to remain some tiny race somewhere.
> Yes at the time of the bonding interface coming up there can be a message about 0 Mbps in dmesg,
> however the actual bond once fully up will have the correct speeds as seen by:
> #cat /proc/net/bonding/bond0
>
> Thanks,
> Emil
>
>

[net-next 5/8] ixgbe: Correct handling of any outer UDP checksum setting

[Jeff Kirsher]

From: Mark Rustad <mark.d.rustad@intel.com>

If an outer UDP checksum is set, pass the skb up with CHECKSUM_NONE
so that the stack will check the checksum. Do not increment an
error counter, because we don't know that there is an actual error.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index ea9537d..a12f93d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -1483,7 +1483,7 @@ static inline void ixgbe_rx_checksum(struct ixgbe_ring *ring,
 			return;
 
 		if (ixgbe_test_staterr(rx_desc, IXGBE_RXDADV_ERR_OUTERIPER)) {
-			ring->rx_stats.csum_err++;
+			skb->ip_summed = CHECKSUM_NONE;
 			return;
 		}
 		/* If we checked the outer header let the stack know */
-- 
2.5.0

[net-next 6/8] ixgbe: Fix to get FDMI HBA attributes information with X550

[Jeff Kirsher]

From: Usha Ketineni <usha.k.ketineni@intel.com>

Check whether the FCOE support is enabled for the devices to get the
 FDMI HBA attributes information instead of checking each device id.
Also, add Model string information for X550.

Signed-off-by: Usha Ketineni <usha.k.ketineni@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index 5982937..df1647f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -996,8 +996,7 @@ int ixgbe_fcoe_get_hbainfo(struct net_device *netdev,
 		return -EINVAL;
 
 	/* Don't return information on unsupported devices */
-	if (hw->mac.type != ixgbe_mac_82599EB &&
-	    hw->mac.type != ixgbe_mac_X540)
+	if (!(adapter->flags & IXGBE_FLAG_FCOE_ENABLED))
 		return -EINVAL;
 
 	/* Manufacturer */
@@ -1043,6 +1042,10 @@ int ixgbe_fcoe_get_hbainfo(struct net_device *netdev,
 		snprintf(info->model,
 			 sizeof(info->model),
 			 "Intel 82599");
+	} else if (hw->mac.type == ixgbe_mac_X550) {
+		snprintf(info->model,
+			 sizeof(info->model),
+			 "Intel X550");
 	} else {
 		snprintf(info->model,
 			 sizeof(info->model),
-- 
2.5.0

[net-next 7/8] ixgbe: Fix MDD events generated when FCoE+SRIOV are enabled

[Jeff Kirsher]

From: Neerav Parikh <neerav.parikh@intel.com>

When FCoE is enabled with SR-IOV on the X550 NIC the hardware
generates MDD events.

This patch fixes these by setting the expected values in the
Tx context descriptors for FCoE/FIP frames and adding a flush
after writing the RDLEN register.

Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 5 ++++-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +++
 drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index df1647f..2a653ec 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -517,6 +517,7 @@ int ixgbe_fso(struct ixgbe_ring *tx_ring,
 	u32 vlan_macip_lens;
 	u32 fcoe_sof_eof = 0;
 	u32 mss_l4len_idx;
+	u32 type_tucmd = IXGBE_ADVTXT_TUCMD_FCOE;
 	u8 sof, eof;
 
 	if (skb_is_gso(skb) && (skb_shinfo(skb)->gso_type != SKB_GSO_FCOE)) {
@@ -593,6 +594,8 @@ int ixgbe_fso(struct ixgbe_ring *tx_ring,
 					       skb_shinfo(skb)->gso_size);
 		first->bytecount += (first->gso_segs - 1) * *hdr_len;
 		first->tx_flags |= IXGBE_TX_FLAGS_TSO;
+		/* Hardware expects L4T to be RSV for FCoE TSO */
+		type_tucmd |= IXGBE_ADVTXD_TUCMD_L4T_RSV;
 	}
 
 	/* set flag indicating FCOE to ixgbe_tx_map call */
@@ -610,7 +613,7 @@ int ixgbe_fso(struct ixgbe_ring *tx_ring,
 
 	/* write context desc */
 	ixgbe_tx_ctxtdesc(tx_ring, vlan_macip_lens, fcoe_sof_eof,
-			  IXGBE_ADVTXT_TUCMD_FCOE, mss_l4len_idx);
+			  type_tucmd, mss_l4len_idx);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a12f93d..328d7a8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -3619,6 +3619,9 @@ void ixgbe_configure_rx_ring(struct ixgbe_adapter *adapter,
 	IXGBE_WRITE_REG(hw, IXGBE_RDBAH(reg_idx), (rdba >> 32));
 	IXGBE_WRITE_REG(hw, IXGBE_RDLEN(reg_idx),
 			ring->count * sizeof(union ixgbe_adv_rx_desc));
+	/* Force flushing of IXGBE_RDLEN to prevent MDD */
+	IXGBE_WRITE_FLUSH(hw);
+
 	IXGBE_WRITE_REG(hw, IXGBE_RDH(reg_idx), 0);
 	IXGBE_WRITE_REG(hw, IXGBE_RDT(reg_idx), 0);
 	ring->tail = adapter->io_addr + IXGBE_RDT(reg_idx);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index 5f53cc6..bf7367a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -2780,6 +2780,7 @@ struct ixgbe_adv_tx_context_desc {
 #define IXGBE_ADVTXD_TUCMD_L4T_UDP   0x00000000  /* L4 Packet TYPE of UDP */
 #define IXGBE_ADVTXD_TUCMD_L4T_TCP   0x00000800  /* L4 Packet TYPE of TCP */
 #define IXGBE_ADVTXD_TUCMD_L4T_SCTP  0x00001000  /* L4 Packet TYPE of SCTP */
+#define IXGBE_ADVTXD_TUCMD_L4T_RSV     0x00001800 /* RSV L4 Packet TYPE */
 #define IXGBE_ADVTXD_TUCMD_MKRREQ    0x00002000 /*Req requires Markers and CRC*/
 #define IXGBE_ADVTXD_POPTS_IPSEC      0x00000400 /* IPSec offload request */
 #define IXGBE_ADVTXD_TUCMD_IPSEC_TYPE_ESP 0x00002000 /* IPSec Type ESP */
-- 
2.5.0

[net-next 8/8] ixgbe: Make ATR recognize IPv6 extended headers

[Jeff Kirsher]

From: Mark Rustad <mark.d.rustad@intel.com>

Right now ATR is not handling IPv6 extended headers, so ATR is not
being performed on such packets. Fix that by skipping extended
headers when they are present. This also fixes a problem where
the ATR code was not checking that the inner protocol was actually
TCP before setting up the signature rules. Since the protocol check
is intimately involved with the extended header processing as well,
this all gets fixed together.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 47 +++++++++++++++++++++------
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 328d7a8..c4003a8 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7573,7 +7573,9 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
 	/* snag network header to get L4 type and address */
 	skb = first->skb;
 	hdr.network = skb_network_header(skb);
-	if (skb->encapsulation) {
+	if (!skb->encapsulation) {
+		th = tcp_hdr(skb);
+	} else {
 #ifdef CONFIG_IXGBE_VXLAN
 		struct ixgbe_adapter *adapter = q_vector->adapter;
 
@@ -7592,14 +7594,34 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
 #else
 		return;
 #endif /* CONFIG_IXGBE_VXLAN */
-	} else {
-		/* Currently only IPv4/IPv6 with TCP is supported */
-		if ((first->protocol != htons(ETH_P_IPV6) ||
-		     hdr.ipv6->nexthdr != IPPROTO_TCP) &&
-		    (first->protocol != htons(ETH_P_IP) ||
-		     hdr.ipv4->protocol != IPPROTO_TCP))
+	}
+
+	/* Currently only IPv4/IPv6 with TCP is supported */
+	switch (hdr.ipv4->version) {
+	case IPVERSION:
+		if (hdr.ipv4->protocol != IPPROTO_TCP)
 			return;
-		th = tcp_hdr(skb);
+		break;
+	case 6:
+		if (likely((unsigned char *)th - hdr.network ==
+			   sizeof(struct ipv6hdr))) {
+			if (hdr.ipv6->nexthdr != IPPROTO_TCP)
+				return;
+		} else {
+			__be16 frag_off;
+			u8 l4_hdr;
+
+			ipv6_skip_exthdr(skb, hdr.network - skb->data +
+					      sizeof(struct ipv6hdr),
+					 &l4_hdr, &frag_off);
+			if (unlikely(frag_off))
+				return;
+			if (l4_hdr != IPPROTO_TCP)
+				return;
+		}
+		break;
+	default:
+		return;
 	}
 
 	/* skip this packet since it is invalid or the socket is closing */
@@ -7634,10 +7656,12 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
 		common.port.src ^= th->dest ^ first->protocol;
 	common.port.dst ^= th->source;
 
-	if (first->protocol == htons(ETH_P_IP)) {
+	switch (hdr.ipv4->version) {
+	case IPVERSION:
 		input.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_TCPV4;
 		common.ip ^= hdr.ipv4->saddr ^ hdr.ipv4->daddr;
-	} else {
+		break;
+	case 6:
 		input.formatted.flow_type = IXGBE_ATR_FLOW_TYPE_TCPV6;
 		common.ip ^= hdr.ipv6->saddr.s6_addr32[0] ^
 			     hdr.ipv6->saddr.s6_addr32[1] ^
@@ -7647,6 +7671,9 @@ static void ixgbe_atr(struct ixgbe_ring *ring,
 			     hdr.ipv6->daddr.s6_addr32[1] ^
 			     hdr.ipv6->daddr.s6_addr32[2] ^
 			     hdr.ipv6->daddr.s6_addr32[3];
+		break;
+	default:
+		break;
 	}
 
 #ifdef CONFIG_IXGBE_VXLAN
-- 
2.5.0

Re: [net-next 0/8][pull request] 10GbE Intel Wired LAN Driver Updates 2016-01-08

[David Miller]

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri,  8 Jan 2016 05:00:22 -0800

> This series contains updates to ixgbe only.

Pulled, thanks Jeff.