From patchwork Tue Jan 2 20:34:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 13509348 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 A9071168AA for ; Tue, 2 Jan 2024 20:34:36 +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="dBWoNgo5" Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-50e759ece35so7540752e87.3 for ; Tue, 02 Jan 2024 12:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704227674; x=1704832474; 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=1M9nYN3vG6J30yAr/55QkQJHhhME7G4QwBy/DGljMWQ=; b=dBWoNgo5PygEcC9HMkb5J8G3zVrW34Vd60E8oSa69CsPq3v7ZNeInou1ajtqfeynNL LOhUP0GryNId1+I/b5EvwRhjCfuNjRhzn2Awr0SUnzbA+Bex3+wvO9Zn309aNZ9dZTHy FkXlxKDVitRnFynCQoyfm0JPUNe4XVnLVSR/pjtNs69EX1zKT71QV4yzIhmzmFVlEShq NvGMq7cupxhAXToeiw/qQm5bpTNuERUoGrtSNeOS3ieI5V51sbo1mhgNN03FA61/4gQP S9NT2nJiouyQJ+MPG/BPLWgzbF7CMZ/cAfI+MG+SJ+KKnRo0knmq5r8M6k+aJvACBSph EqAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704227674; x=1704832474; 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=1M9nYN3vG6J30yAr/55QkQJHhhME7G4QwBy/DGljMWQ=; b=LPoOnJDUvHZvXI4lg0dde8v3s0cG3X94RaA/VCM0FV2ZqUS6UXc4jv49DRuW0W3wt2 A1nhEWtgGqttG1qaa042B5q2rn5EZa5N6ibh8URseooWbE5qSBRsbBhtKV+qqiEAg/Lf MvbbtxIBeAdym2CssUhXaaYrnIsGOb4szg6sUSHRKmq2hn5vlR6EtOkHO/awma7vmkfY s8t4U32QVvAZWjMst3QlxXwCbnS2J/N4zFoxrn+eAv5asheqZ4qvYqUD6+/0DlVCReX9 PDrRXdejZVVbXZqIph/K9mOQyGF/mKFh6NWiqthrSyro0KATamOzh5ooJ2soOBvEsG/k 3tJQ== X-Gm-Message-State: AOJu0YyzLU7sh7JoGQFgt90mpMyOOmq1+utzcWvLeGiLj4RzI+jRzGZN KscXu9LM927HkZo1Cv0cHeJEBtH2xE34Bg== X-Google-Smtp-Source: AGHT+IELY2RrI4v5BL6TZkjmiBBdx1iS+Ih9bElowArkthdxzgBDg9lZEcLiiHvbEL8Q/G4RFbWmKg== X-Received: by 2002:a05:6512:2346:b0:50e:7dd2:4104 with SMTP id p6-20020a056512234600b0050e7dd24104mr6792899lfu.56.1704227674119; Tue, 02 Jan 2024 12:34:34 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id a19-20020ac25213000000b0050e7b52c735sm2668392lfl.145.2024.01.02.12.34.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 12:34:33 -0800 (PST) From: Linus Walleij Date: Tue, 02 Jan 2024 21:34:25 +0100 Subject: [PATCH net v5 1/2] 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: <20240102-new-gemini-ethernet-regression-v5-1-cf61ab3aa8cd@linaro.org> References: <20240102-new-gemini-ethernet-regression-v5-0-cf61ab3aa8cd@linaro.org> In-Reply-To: <20240102-new-gemini-ethernet-regression-v5-0-cf61ab3aa8cd@linaro.org> To: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vladimir Oltean , Household Cang , Romain Gantois 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 | 35 ++++------------------------------- 1 file changed, 4 insertions(+), 31 deletions(-) diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 78287cfcbf63..5e399c6e095b 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 @@ -1143,39 +1142,13 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, struct gmac_txdesc *txd; skb_frag_t *skb_frag; dma_addr_t mapping; - unsigned short mtu; void *buffer; - int ret; - - mtu = ETH_HLEN; - mtu += netdev->mtu; - if (skb->protocol == htons(ETH_P_8021Q)) - mtu += VLAN_HLEN; + /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; - word3 = SOF_BIT; - - if (word1 > mtu) { - word1 |= TSS_MTU_ENABLE_BIT; - word3 |= mtu; - } + word3 = SOF_BIT | skb->len; - 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 Tue Jan 2 20:34:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 13509349 X-Patchwork-Delegate: kuba@kernel.org Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) (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 B5F01168AC for ; Tue, 2 Jan 2024 20:34:36 +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="aNJpyEYE" Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-50e77a2805fso6818042e87.1 for ; Tue, 02 Jan 2024 12:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704227675; x=1704832475; 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=ci97zJBKMv+90pMXEKok7iRatK5RIKi/NRVSmudTOIQ=; b=aNJpyEYENFcKBtrmLnZoZrjO7NFTMORr8iM0NfG/WNj9pCDjgFL3RKxLS9Z+FbdXUV URXXrME+qNRowhsREHdacOeyz3oh8le/MerrVd2JjDiGmC10wCv8Io4nqrMPDeqs9YVx VC9G/Btrvui4J8klWTfFQhw4yP3ZkYNXkc1U1RD+0VCohUpmVIJTf+clTSGDeObNAIqG ajwm+5OUutqd6/H0wbqqWYng2bIA1I9ITtbF0cgAcCydCgOSHtWn+pYRLELdzxJ8Gmxd Jj6CbNC8xKzsVPUgylnHLF5w7rylvpkI8Gy8tCVkWyxpTTM2/75LUSN2wbQM8qbe1wTi 2nQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704227675; x=1704832475; 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=ci97zJBKMv+90pMXEKok7iRatK5RIKi/NRVSmudTOIQ=; b=T69XADlP/mk/P5JO6enCek5k6UwGx+jKAHGkChV0BwbwqQuJPBgYM2hNqCKSNUDvdC KrM5AfBuy1t1niDeK0o9XzsUTdfxihz5q5DxMliU33Iu/4xPbymwEPWJyWhxKplpcskP sYQJA0XWM2czK/kPI7y5kqeK5xq87lTlRXkI9dGPjEIqphLVw3HU3VH9WbhdXbAhgO01 RRTd12c9oqVre79eYNBQgkDpiODpoJ41cPoIBwURcwejMkgX+O7YoS1n5KiI8fiWR8Wp RgL7t1Np930uGaU3ZU6I3P9C7cgTki+YM1ZYItNDRctIk24JVn6koBpCKYtsN+UeGh2q s+JA== X-Gm-Message-State: AOJu0YwMIup2QBHe/umz/w+xKGQqPv0jKQm2rLr8V8vCQqr0WR3HYlHa R4s8Tk9rGQSN/A9+gJ+RiTyHgOHARTc8Lg== X-Google-Smtp-Source: AGHT+IH9dlfjIS5vApOqD3R3SBUmxsi5JvZhfrmohGt1S2dfe6GPXIccdxg6aiBoTPv+tJh5r8VjAg== X-Received: by 2002:a05:6512:4001:b0:50e:633e:4cc9 with SMTP id br1-20020a056512400100b0050e633e4cc9mr6878442lfb.204.1704227674912; Tue, 02 Jan 2024 12:34:34 -0800 (PST) Received: from [127.0.1.1] ([85.235.12.238]) by smtp.gmail.com with ESMTPSA id a19-20020ac25213000000b0050e7b52c735sm2668392lfl.145.2024.01.02.12.34.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 12:34:34 -0800 (PST) From: Linus Walleij Date: Tue, 02 Jan 2024 21:34:26 +0100 Subject: [PATCH net v5 2/2] 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: <20240102-new-gemini-ethernet-regression-v5-2-cf61ab3aa8cd@linaro.org> References: <20240102-new-gemini-ethernet-regression-v5-0-cf61ab3aa8cd@linaro.org> In-Reply-To: <20240102-new-gemini-ethernet-regression-v5-0-cf61ab3aa8cd@linaro.org> To: Hans Ulli Kroll , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vladimir Oltean , Household Cang , Romain Gantois 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 don't activate 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. If the frame is ALSO over the size of an ordinary ethernet frame, we will actively bypass the checksumming engine. (Always doing this makes the hardware unstable.) 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 | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/cortina/gemini.c b/drivers/net/ethernet/cortina/gemini.c index 5e399c6e095b..68da4ae26248 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 @@ -1142,22 +1143,38 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, struct gmac_txdesc *txd; skb_frag_t *skb_frag; dma_addr_t mapping; + u16 ethertype; void *buffer; /* TODO: implement proper TSO using MTU in word3 */ word1 = skb->len; word3 = SOF_BIT | skb->len; - 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 = ntohs(eth_header_parse_protocol(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 = ntohs(__vlan_get_protocol(skb, htons(ethertype), NULL)); + + 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. When a frame gets bigger than a standard ethernet + * frame, it also needs to actively bypass the checksumming engine. + * There is no clear explanation to why it is like this, the + * reference manual has left the TSS completely undocumented. + */ + if (skb->len > ETH_FRAME_LEN) + 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 - * frames: as is shown from tests, the checksumming engine - * is smart enough to see that a frame is not actually TCP - * or UDP and then just pass it through without any changes - * to the frame. - */ - if (skb->protocol == htons(ETH_P_IP)) { + if (ethertype == ETH_P_IP) { word1 |= TSS_IP_CHKSUM_BIT; tcp = ip_hdr(skb)->protocol == IPPROTO_TCP; } else { /* IPv6 */