netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
	netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
	jogreene@redhat.com, guru.anbalagane@oracle.com
Subject: [net-next 01/18] i40e: Be much more verbose about what we can and cannot offload
Date: Sat,  3 Dec 2016 01:19:13 -0800	[thread overview]
Message-ID: <20161203091930.14268-2-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20161203091930.14268-1-jeffrey.t.kirsher@intel.com>

From: Alexander Duyck <alexander.h.duyck@intel.com>

This change makes it so that we are much more robust about defining what we
can and cannot offload.  Previously we were just checking for the L4 tunnel
header length, however there are other fields we should be verifying as
there are multiple scenarios in which we cannot perform hardware offloads.

In addition the device only supports GSO as long as the MSS is 64 or
greater.  We were not checking this so an MSS less than that was resulting
in Tx hangs.

Change-ID: I5e2fd5f3075c73601b4b36327b771c64fcb6c31b
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 52 ++++++++++++++++++++++++-----
 1 file changed, 44 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 5c6a5ce..2d91274 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9070,10 +9070,6 @@ static int i40e_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
 				       0, 0, nlflags, filter_mask, NULL);
 }
 
-/* Hardware supports L4 tunnel length of 128B (=2^7) which includes
- * inner mac plus all inner ethertypes.
- */
-#define I40E_MAX_TUNNEL_HDR_LEN 128
 /**
  * i40e_features_check - Validate encapsulated packet conforms to limits
  * @skb: skb buff
@@ -9084,12 +9080,52 @@ static netdev_features_t i40e_features_check(struct sk_buff *skb,
 					     struct net_device *dev,
 					     netdev_features_t features)
 {
-	if (skb->encapsulation &&
-	    ((skb_inner_network_header(skb) - skb_transport_header(skb)) >
-	     I40E_MAX_TUNNEL_HDR_LEN))
-		return features & ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
+	size_t len;
+
+	/* No point in doing any of this if neither checksum nor GSO are
+	 * being requested for this frame.  We can rule out both by just
+	 * checking for CHECKSUM_PARTIAL
+	 */
+	if (skb->ip_summed != CHECKSUM_PARTIAL)
+		return features;
+
+	/* We cannot support GSO if the MSS is going to be less than
+	 * 64 bytes.  If it is then we need to drop support for GSO.
+	 */
+	if (skb_is_gso(skb) && (skb_shinfo(skb)->gso_size < 64))
+		features &= ~NETIF_F_GSO_MASK;
+
+	/* MACLEN can support at most 63 words */
+	len = skb_network_header(skb) - skb->data;
+	if (len & ~(63 * 2))
+		goto out_err;
+
+	/* IPLEN and EIPLEN can support at most 127 dwords */
+	len = skb_transport_header(skb) - skb_network_header(skb);
+	if (len & ~(127 * 4))
+		goto out_err;
+
+	if (skb->encapsulation) {
+		/* L4TUNLEN can support 127 words */
+		len = skb_inner_network_header(skb) - skb_transport_header(skb);
+		if (len & ~(127 * 2))
+			goto out_err;
+
+		/* IPLEN can support at most 127 dwords */
+		len = skb_inner_transport_header(skb) -
+		      skb_inner_network_header(skb);
+		if (len & ~(127 * 4))
+			goto out_err;
+	}
+
+	/* No need to validate L4LEN as TCP is the only protocol with a
+	 * a flexible value and we support all possible values supported
+	 * by TCP, which is at most 15 dwords
+	 */
 
 	return features;
+out_err:
+	return features & ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
 }
 
 static const struct net_device_ops i40e_netdev_ops = {
-- 
2.9.3

  reply	other threads:[~2016-12-03  9:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-03  9:19 [net-next 00/18][pull request] 40GbE Intel Wired LAN Driver Updates 2016-12-02 Jeff Kirsher
2016-12-03  9:19 ` Jeff Kirsher [this message]
2016-12-03  9:19 ` [net-next 02/18] i40evf: Be much more verbose about what we can and cannot offload Jeff Kirsher
2016-12-03  9:19 ` [net-next 03/18] i40e: remove error_param_int label from i40e_vc_config_promiscuous_mode_msg Jeff Kirsher
2016-12-03  9:19 ` [net-next 04/18] i40e: remove second check of VLAN_N_VID in i40e_vlan_rx_add_vid Jeff Kirsher
2016-12-03  9:19 ` [net-next 05/18] i40e: avoid duplicate private flags definitions Jeff Kirsher
2016-12-03  9:19 ` [net-next 06/18] i40e: Add Clause22 implementation Jeff Kirsher
2016-12-03  9:19 ` [net-next 07/18] i40e: fix trivial typo in naming of i40e_sync_filters_subtask Jeff Kirsher
2016-12-03  9:19 ` [net-next 08/18] i40e: Add protocols over MCTP to i40e_aq_discover_capabilities Jeff Kirsher
2016-12-03  9:19 ` [net-next 09/18] i40e: fix panic on SPARC while changing num of desc Jeff Kirsher
2016-12-03  9:19 ` [net-next 10/18] i40evf: Move some i40evf_reset_task code to separate function Jeff Kirsher
2016-12-03  9:19 ` [net-next 11/18] i40evf: check for msix_entries null dereference Jeff Kirsher
2016-12-03  9:19 ` [net-next 12/18] i40e: Remove unreachable code Jeff Kirsher
2016-12-03  9:19 ` [net-next 13/18] i40e: Pass unknown PHY type for unknown PHYs Jeff Kirsher
2016-12-03  9:19 ` [net-next 14/18] i40evf: protect against NULL msix_entries and q_vectors pointers Jeff Kirsher
2016-12-03  9:19 ` [net-next 15/18] i40e: Fix for ethtool Supported link modes Jeff Kirsher
2016-12-03  9:19 ` [net-next 16/18] i40e: set broadcast promiscuous mode for each active VLAN Jeff Kirsher
2016-12-03  9:19 ` [net-next 17/18] i40e/i40evf: replace for memcpy with single memcpy call in ethtool Jeff Kirsher
2016-12-03  9:19 ` [net-next 18/18] i40e: change message to only appear when extra debug info is wanted Jeff Kirsher
2016-12-04  0:11 ` [net-next 00/18][pull request] 40GbE Intel Wired LAN Driver Updates 2016-12-02 David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161203091930.14268-2-jeffrey.t.kirsher@intel.com \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=guru.anbalagane@oracle.com \
    --cc=jogreene@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=sassmann@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).