From patchwork Thu Dec 21 00:02:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 13500835 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C289A433A6 for ; Thu, 21 Dec 2023 00:02:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Z7uJvkq3" Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-50c0f13ea11so309643e87.3 for ; Wed, 20 Dec 2023 16:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1703116962; x=1703721762; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=xBDD0R1VzHn04ZqBmcTCc/UmHgjO4/zmLvPSgWyQBHQ=; b=Z7uJvkq3DnlxwDtWbE+epa1qmxRcRIFeAb5KXHuEYZbXiYL1B0cQ/Qz93AUq7D5lgP jY2CVRu/f6kcrJfCdFX8adDNKUeTwR9wmKdbhnaPe2LrdT4Io7MdbFx3DMYv5KojDY9k Ub3tAlHvgMxX6gNAxsBffMahCTO98M05M2qnFyMl5FYOfs+UoLDtfR4ofMcxK+ZPKGLA yEnIvcqyufGB6jSQBPFj2kg5rLz62MZFsrAu/pHC0pT8Gfw25G018Dm9c6Tpw0SGKUvI rCQVvE2JmR0OyjPkOhzkfkE0g/bFuRKW2p9zMTLluox/fIXng0QgXtbu0HsxLsJpoc3I zUoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703116962; x=1703721762; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xBDD0R1VzHn04ZqBmcTCc/UmHgjO4/zmLvPSgWyQBHQ=; b=Pk7+GuclJGIpAQEEdc83iMrUsyu46Gc+w1U2Stou9ZejuQctB1Aso2bevqlXfwIP3C Xn1gwYWsurB6locof8EPEAUoYMq2cjH0vMFtnrkRYkj8qhTXadyjVZEoOKIRKmT4XXbv GD2b2a5rB1O3A3/djjVq0u5081F0+9r9llV+umkO8/z/RqAJ+weTtgpuX7+xb+x0CEmP jaO6mNYDJ8wQc1eSnJ9HCJg/E0RLzI8Hk7gIpD3zNqaxGeiufmi09qRMatBgN4A2930T usweS4A7BAptyd8J+SRvjbfcej+rody7itykaZNswCy5thuzSDr/G03XqtpKTjA80PZe Kvhg== X-Gm-Message-State: AOJu0Yw8cP82JkkP/8Mw93BxSBB6RVK1AlVZgHt03B/huNDOD5HUv32l ARe+/nal4aElsOMXenT6ww96uw== X-Google-Smtp-Source: AGHT+IE9vovWa2oEaTXPQ/5pFhmMSE8TvFmpLGCQ2fhM/PpdpCW6+Lgc17iCMbIuZgRM2VVnZmXXjw== X-Received: by 2002:a05:6512:78:b0:50e:55bb:a453 with SMTP id i24-20020a056512007800b0050e55bba453mr685783lfo.3.1703116961756; Wed, 20 Dec 2023 16:02:41 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id v26-20020a19741a000000b0050e4ac5bf5asm100321lfe.284.2023.12.20.16.02.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 16:02:40 -0800 (PST) From: Linus Walleij Date: Thu, 21 Dec 2023 01:02:20 +0100 Subject: [PATCH net v3 1/3] net: ethernet: cortina: Drop software checksum and TSO Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20231221-new-gemini-ethernet-regression-v3-1-a96b4374bfe8@linaro.org> References: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> In-Reply-To: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> To: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: netdev@vger.kernel.org, Linus Walleij X-Mailer: b4 0.12.4 X-Patchwork-Delegate: kuba@kernel.org The recent change to allow large frames without hardware checksumming slotted in software checksumming in the driver if hardware could not do it. This will however upset TSO (TCP Segment Offloading). Typical error dumps includes this: skb len=2961 headroom=222 headlen=66 tailroom=0 (...) WARNING: CPU: 0 PID: 956 at net/core/dev.c:3259 skb_warn_bad_offload+0x7c/0x108 gemini-ethernet-port: caps=(0x0000010000154813, 0x00002007ffdd7889) And the packets do not go through. After investigating I drilled it down to the introduction of the software checksumming in the driver. Since the segmenting of packets will be done by the hardware this makes a bit of sense since in that case the hardware also needs to be keeping track of the checksumming. That begs the question why large TCP or UDP packets also have to bypass the checksumming (like e.g. ICMP does). If the hardware is splitting it into smaller packets per-MTU setting, and checksumming them, why is this happening then? I don't know. I know it is needed, from tests: the OpenWrt webserver uhttpd starts sending big skb:s (up to 2047 bytes, the max MTU) and above 1514 bytes it starts to fail and hang unless the bypass bit is set: the frames are not getting through. Drop the size check and the offloading features for now: this needs to be fixed up properly. Suggested-by: Eric Dumazet Fixes: d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") Signed-off-by: Linus Walleij --- drivers/net/ethernet/cortina/gemini.c | 21 ++------------------- 1 file changed, 2 insertions(+), 19 deletions(-) diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 78287cfcbf63..ecc247acac39 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -79,8 +79,7 @@ MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)"); #define GMAC0_IRQ4_8 (GMAC0_MIB_INT_BIT | GMAC0_RX_OVERRUN_INT_BIT) #define GMAC_OFFLOAD_FEATURES (NETIF_F_SG | NETIF_F_IP_CSUM | \ - NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM | \ - NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) + NETIF_F_IPV6_CSUM | NETIF_F_RXCSUM) /** * struct gmac_queue_page - page buffer per-page info @@ -1145,7 +1144,6 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, dma_addr_t mapping; unsigned short mtu; void *buffer; - int ret; mtu = ETH_HLEN; mtu += netdev->mtu; @@ -1160,22 +1158,7 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, word3 |= mtu; } - if (skb->len >= ETH_FRAME_LEN) { - /* Hardware offloaded checksumming isn't working on frames - * bigger than 1514 bytes. A hypothesis about this is that the - * checksum buffer is only 1518 bytes, so when the frames get - * bigger they get truncated, or the last few bytes get - * overwritten by the FCS. - * - * Just use software checksumming and bypass on bigger frames. - */ - if (skb->ip_summed == CHECKSUM_PARTIAL) { - ret = skb_checksum_help(skb); - if (ret) - return ret; - } - word1 |= TSS_BYPASS_BIT; - } else if (skb->ip_summed == CHECKSUM_PARTIAL) { + if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP From patchwork Thu Dec 21 00:02:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 13500836 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A88C6433CA for ; Thu, 21 Dec 2023 00:02:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="kc4gz5R8" Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2cc3f5e7451so1909071fa.2 for ; Wed, 20 Dec 2023 16:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1703116962; x=1703721762; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=HzhpH0J3TXUoWqEafbYmXb/5rBmLt887S+CmrUg/4PI=; b=kc4gz5R8ycupIs46wM5vNeERIMn/0bG6v8QRYPEeIJRMv8Nm4q7pw/TkyZIIgayqQB X7QH0W8+bsSpWh4Hs2paRwyj3uUMKSp9MROVir6lq1jnippMHpSBkInNwPWG40DJiH+J 3XgmDDOjXFbBBJteZLpxEu4LDx686q2nq8fTy34kpypAZvPOLs6wnb0oauqM+alctmok eC4m9999A11sEmFIjvfdGQ85dW862ub7/6JP3pFfCPGbQS5xdFbSMIl3lyLszs8pfrN+ AlymiR4mj7wtN6UP1pIYxNiyws8O4JZJJy1Lk89scHKfLGoje3E4KHx9fTIvjulFUp/Y jebg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703116962; x=1703721762; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HzhpH0J3TXUoWqEafbYmXb/5rBmLt887S+CmrUg/4PI=; b=vRv1jlMt9P2yFnmuK7keuyQwWnUuAZOZ8hiezYOdfbhmxpFPC9a6WaMFND8vsdljUv d505i6Gzhl/WOrhdiQThCpMHNkInaEunSKwgW28k8axIMdkYyKIGh1QcjHm2HGTxe45J JeY174qnc19t9VdD9BGjAzwX/6ffbvBxhN5aYvi18hGQZ5TxJhdCbyTZb3lDz+cVjcd5 HyAfmC/R7JUrYlK4FUvrqXxe0ORvCQlS8wMuUCdsHpwcDJbo4xkkMzU8tBt0YieYZjoj +wy8u5BoRu9HWluUrAl4bsghDWgyA33cZpMG27h0nqMWJh1K+jJFAMJ20TKZZ+7Oqy7e rEBA== X-Gm-Message-State: AOJu0YzH/jA5esDhvCkGizrojTnUYRboxhMAyUBYuKCaYQv+bc7pjVdj SiA6mE9olQVASOQzeoSyp+aaQA== X-Google-Smtp-Source: AGHT+IEmxS6nsTZFx5eJB/F2NUTJW8o1tb0jbv1dJWfa683uFn2oM/6zz8xJ9omZuzbMlkFSQUhonw== X-Received: by 2002:a05:6512:10c4:b0:50e:5889:e5ac with SMTP id k4-20020a05651210c400b0050e5889e5acmr532307lfg.71.1703116962762; Wed, 20 Dec 2023 16:02:42 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id v26-20020a19741a000000b0050e4ac5bf5asm100321lfe.284.2023.12.20.16.02.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 16:02:42 -0800 (PST) From: Linus Walleij Date: Thu, 21 Dec 2023 01:02:21 +0100 Subject: [PATCH net v3 2/3] if_ether: Add an accessor to read the raw ethertype Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20231221-new-gemini-ethernet-regression-v3-2-a96b4374bfe8@linaro.org> References: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> In-Reply-To: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> To: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: netdev@vger.kernel.org, Linus Walleij , Maxime Chevallier X-Mailer: b4 0.12.4 X-Patchwork-Delegate: kuba@kernel.org There are circumstances where the skb->protocol can not be trusted, such as when using DSA switches that add a custom ethertype to the ethernet packet, which is later on supposed to be stripped by the switch hardware connected to the conduit ethernet interface. Since ethernet drivers transmitting such frames with alien ethertypes can have hardware that will get confused by custom ethertypes they need a way to retrieve and act on any such type. The new eth_skb_raw_ethertype() helper will extract the ethertype directly from the skb->data using the ethernet and (if necessary) VLAN helper functions, and return the ethertype actually found inside the raw buffer. Suggested-by: Maxime Chevallier Suggested-by: Eric Dumazet Signed-off-by: Linus Walleij --- include/linux/if_ether.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h index 8a9792a6427a..6bf265979757 100644 --- a/include/linux/if_ether.h +++ b/include/linux/if_ether.h @@ -37,6 +37,22 @@ static inline struct ethhdr *inner_eth_hdr(const struct sk_buff *skb) return (struct ethhdr *)skb_inner_mac_header(skb); } +/* This determines the ethertype incoded into the skb data without + * relying on skb->protocol which is not always identical. + */ +static inline u16 skb_eth_raw_ethertype(struct sk_buff *skb) +{ + struct ethhdr *hdr; + + /* If we can't extract a header, return invalid type */ + if (!pskb_may_pull(skb, ETH_HLEN)) + return 0x0000U; + + hdr = skb_eth_hdr(skb); + + return ntohs(hdr->h_proto); +} + int eth_header_parse(const struct sk_buff *skb, unsigned char *haddr); extern ssize_t sysfs_format_mac(char *buf, const unsigned char *addr, int len); From patchwork Thu Dec 21 00:02:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 13500837 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D85AF446A2 for ; Thu, 21 Dec 2023 00:02:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="d6YR8+uH" Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-50dfac6c0beso323540e87.2 for ; Wed, 20 Dec 2023 16:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1703116964; x=1703721764; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=lJLMGs1lZHtbdX/Mvsz/3hJzF7Azi3GTCJ3LJqHm/1E=; b=d6YR8+uH8jZga/zOP4TqUCaqmkn8le5qm03iE8EiYWFDo4ML1cJgFKw3pS+vgI2YIF zhx4/9mC2zyHU7Uu30o+DOPYDWA7f0Gega+kxM+9GUp+3sitPvr9FJi3Se7IHCmDFB2G CspJG9MBHgqYjW07sze0cty0XWGLvgw6tfDl5G+4O9LJ9mWsbWtCQL5IsMrUYvNRoA2N gqRFwe89MuW1tWjwbflh/14H6ctBltRH2GGA56rcVAVIm23Ub8K4m58SKpJ697yYyjfF YcYDKR3ffZl4bozIySbV5BLcfDvK8zxRXFTHcbpo0/l1j0jWjawqd6/jJZyWbUk8otMO 7v6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703116964; x=1703721764; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lJLMGs1lZHtbdX/Mvsz/3hJzF7Azi3GTCJ3LJqHm/1E=; b=HkNF34I0h+85m6n+8qmrJAk3U0R9YI3ik8UEjm+2a0VTpgE50Msa5djpYg2gV84uRC 2FUEsmMNcO7UUr2gyk/lRLE+1ZtTZoUiX02c4riWHbjnOmYPC/EkMQuDi1hSHgN1LVQB UBohgFxPrctTZSV/oqH1Mt5yTS4FpG5AdgdUsyhxbVGrOWpzOp5Ll9jeoLrWpCgaEPfs VnW/m787ALzjawoxIxXK5CzTJbGX/CjSPwi079ZHrN2j0id3c4hdinaROFl7g3Q97FdF QiatvuETN82f978SWLWtr7Ye4ve2nwFgUEAqKcV6B+K6MxbcewSMCaw45EQa9u9lVmcr jpog== X-Gm-Message-State: AOJu0Yyevo495k73/B+d+9iLXnkZkenjXjeb9LGgFnnEI1xTRvdzbc3r D8JZ97XkT4eT2BbcdIbt1dnhZw== X-Google-Smtp-Source: AGHT+IE1WX0Y0fiv3yUhbmICABCtXC8/5OkNumN66LfZib/JXWiHTn/R1K783d8eGgvHPWesuzXGiQ== X-Received: by 2002:a05:6512:1584:b0:50e:10e8:d544 with SMTP id bp4-20020a056512158400b0050e10e8d544mr9221601lfb.68.1703116963568; Wed, 20 Dec 2023 16:02:43 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id v26-20020a19741a000000b0050e4ac5bf5asm100321lfe.284.2023.12.20.16.02.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 16:02:43 -0800 (PST) From: Linus Walleij Date: Thu, 21 Dec 2023 01:02:22 +0100 Subject: [PATCH net v3 3/3] net: ethernet: cortina: Bypass checksumming engine of alien ethertypes Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20231221-new-gemini-ethernet-regression-v3-3-a96b4374bfe8@linaro.org> References: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> In-Reply-To: <20231221-new-gemini-ethernet-regression-v3-0-a96b4374bfe8@linaro.org> To: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: netdev@vger.kernel.org, Linus Walleij X-Mailer: b4 0.12.4 X-Patchwork-Delegate: kuba@kernel.org We had workarounds were the ethernet checksumming engine would be bypassed for larger frames, this fixed devices using DSA, but regressed devices where the ethernet was connected directly to a PHY. The devices with a PHY connected directly can't handle large frames either way, with or without bypass. Looking at the size of the frame is probably just wrong. Rework the workaround such that we just bypass the checksumming engine if the ethertype inside the actual frame is something else than 0x0800 (IPv4) or 0x86dd (IPv6). These are the only frames the checksumming engine can actually handle. VLAN framing (0x8100) also works fine. We can't inspect skb->protocol because DSA frames will sometimes have a custom ethertype despite skb->protocol is e.g. 0x0800. After this both devices with direct ethernet attached such as D-Link DNS-313 and devices with a DSA switch with a custom ethertype such as D-Link DIR-685 work fine. Fixes: d4d0c5b4d279 ("net: ethernet: cortina: Handle large frames") Signed-off-by: Linus Walleij --- drivers/net/ethernet/cortina/gemini.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index ecc247acac39..6d153eba8e81 100644 --- a/drivers/net/ethernet/cortina/gemini.c +++ b/drivers/net/ethernet/cortina/gemini.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -1143,6 +1144,7 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, skb_frag_t *skb_frag; dma_addr_t mapping; unsigned short mtu; + u16 ethertype; void *buffer; mtu = ETH_HLEN; @@ -1158,7 +1160,24 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, word3 |= mtu; } - if (skb->ip_summed == CHECKSUM_PARTIAL) { + /* Dig out the the ethertype actually in the buffer and not what the + * protocol claims to be. This is the raw data that the checksumming + * offload engine will have to deal with. + */ + ethertype = skb_eth_raw_ethertype(skb); + /* This is the only VLAN type supported by this hardware so check for + * that: the checksumming engine can handle IP and IPv6 inside 802.1Q. + */ + if (ethertype == ETH_P_8021Q) + ethertype = vlan_get_protocol(skb); + + if (ethertype != ETH_P_IP && ethertype != ETH_P_IPV6) { + /* Hardware offloaded checksumming isn't working on non-IP frames. + * This happens for example on some DSA switches using a custom + * ethertype. Just bypass the engine for those. + */ + word1 |= TSS_BYPASS_BIT; + } else if (skb->ip_summed == CHECKSUM_PARTIAL) { int tcp = 0; /* We do not switch off the checksumming on non TCP/UDP