Received: by 2002:a05:7412:85a1:b0:e2:908c:2ebd with SMTP id n33csp115386rdh; Mon, 30 Oct 2023 16:02:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGQzFLqIyuNTLS960J96umcXooA0V+12KW2O706cxoMsujVJW4wSXYj+pafZ2DC9lhryHLS X-Received: by 2002:a17:902:d306:b0:1c9:fdf0:f69 with SMTP id b6-20020a170902d30600b001c9fdf00f69mr9893515plc.63.1698706948805; Mon, 30 Oct 2023 16:02:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698706948; cv=none; d=google.com; s=arc-20160816; b=VNce4hWJ1dHwiPU2IVFyK2CviKImoONTDgjT2tkaxAMUk3xrKP1xmFp+46Aplqja2e RoeQkTB/DFLQ6NDfrLV6zdqIE2hLKAAU/QFsgGLxrFX1ZWP78OZgkc2trmhXJydHInUo jZTaspKiHPRHbxGe8udLPEh0mtZg5xwksVmhmqQBEBQS33UVduxj/cGCL49KH+t0Div/ EKrrC69iiH9X5ZoskFfXofazRuOaH+KfZ87zWzdwpWtC6ga9sSxPecYVXX1mP4RSemuk S/t1GLOhUcR0Xzm8QGJMZK5jPc6Ekyv4mtqgXVhxn6cMLGjSV9uj5x9mKPBiZdJh7AGP Nxmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=mOqpJwapvpRYXVNPTTKOLnjojsLqC4JocbtWhR4syPY=; fh=7sTgL4l5IxDwN+qfPjFbkHPyuOk3OK8dEYGTT0NLMv0=; b=V5G6Tu7TEtFTJoUzn/0DPWC5UTY9T2NI1q53y5nT8ftGV0CMkdilVP/G6+z+vTHGdn gqLCNEZah6hZ02w03AFOKH2VwXCzc8W5GxM/+zCaqPu/d4m3mnzJbo3IqZO64D36MsPK G11iq7stkbTH5+ev1YBsEOHMEzMyMS4n+VxE2n9jfBUzzEYg8ByWT3wKQMkymwFSHHgq 0BAeLBUNoSbKp/YJjv5DWs5EQ8Q3Ailq88IBzlZ1aBXHwCtqYKC10kOFWELAuamH1HD0 BG7vEay9S6qTB3MKf6kSkNgZE29Y71XBH921TYahQB5Ta+4voU2vbL8zhpI1A3p8ecq7 Gbeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ui07+5Qn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id i3-20020a17090332c300b001c9d4f08c3asi74776plr.277.2023.10.30.16.02.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 16:02:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ui07+5Qn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 1E7CE80B87D5; Mon, 30 Oct 2023 16:02:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232216AbjJ3W5t (ORCPT + 99 others); Mon, 30 Oct 2023 18:57:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229682AbjJ3W5t (ORCPT ); Mon, 30 Oct 2023 18:57:49 -0400 Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7053ADD for ; Mon, 30 Oct 2023 15:57:46 -0700 (PDT) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-5a82c2eb50cso41878487b3.2 for ; Mon, 30 Oct 2023 15:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1698706665; x=1699311465; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mOqpJwapvpRYXVNPTTKOLnjojsLqC4JocbtWhR4syPY=; b=ui07+5Qnn11jUW7iw8DX6C2Sl0WCdv7TQtNg8elsBjFWioSv2tmLFY4jHYqC7n1y+G YbRcEFkyElwmZPFzVSzVPrh/1xSd03krVZrA0j7J+vOeLlN0xeSQP3tMpTP5a6qXqnBD Zg1tbCBKbImExbW3g9Vz8jOblAAB+nVIvSl7n+4LhAPpw5+W80vsIxvpOSIycew4nOgV 96gqtEQrSICD36I0rXYGq+EFQBel09i+kuvaKJRHwtcqd196z3oBmT4S/cgHJRl3bHIv na2zdZteWN3Gy/n3FpRMbwmKmOXQ4OAWv2qNkc5bYP+gP2OdsMK434I0CUn1XKpVDUri Cb+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698706665; x=1699311465; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mOqpJwapvpRYXVNPTTKOLnjojsLqC4JocbtWhR4syPY=; b=JO/S5aiscoGCqVYy5wg85JQ8FJWMEnSr/bASXIe90n1xoTffV6uuFJqI1xu3wTj4xF Lqr1zDWrsU4Hg3B43gFap6iN+mXeRYfgojVQ7RbMK3Gili5d3+7/aaTBRDfDZRpuA7bZ SPqSZUIoBoS6i2vR7mcYe6vE06KT3WDBcBLw+cI1CIoxraXW419b/qGXD/hJw8ji+eMF wXGcfCsyIR2M+/1DFqMSt4KiDtyEZXTsqj67D2fOi+t4FCNW9TY1N2oa7/t403u4cl7U Z+ETovTz7vgYIt5m3EAaFOsqKTO4iz1yn+eJoPkOYsrTpk1EEHqRRTz1D3HnrhQD6Njt k7Ow== X-Gm-Message-State: AOJu0Ywx1FZgrxP68iJvUkwhGDsEnBP4QCA0NOCCCDY6+oJCro8spWXi kuqqh08ZFCE4WKMDIH6nnLidZ2noNXLYFcdzFe/hng== X-Received: by 2002:a81:ca08:0:b0:5a8:1924:b7e7 with SMTP id p8-20020a81ca08000000b005a81924b7e7mr8194231ywi.27.1698706665480; Mon, 30 Oct 2023 15:57:45 -0700 (PDT) MIME-Version: 1.0 References: <20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org> <20231030141623.ufzhb4ttvxi3ukbj@skbuf> <20231030222035.oqos7v7sdq5u6mti@skbuf> In-Reply-To: <20231030222035.oqos7v7sdq5u6mti@skbuf> From: Linus Walleij Date: Mon, 30 Oct 2023 23:57:33 +0100 Message-ID: Subject: Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size To: Vladimir Oltean Cc: Andrew Lunn , Florian Fainelli , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 30 Oct 2023 16:02:26 -0700 (PDT) On Mon, Oct 30, 2023 at 11:20=E2=80=AFPM Vladimir Oltean wrote: > I see commit 86dd9868b878 ("net: dsa: tag_rtl4_a: Support also egress tag= s") > also mentions: "Qingfang came up with the solution: we need to pad the > ethernet frame to 60 bytes using eth_skb_pad(), then the switch will > happily accept frames with custom tags.". So the __skb_put_padto() was > something very empirical in the first place. > > Since it's all problematic, would you mind removing the __skb_put_padto() > altogether from rtl4a_tag_xmit(), and let me know what is the output for > the following sweep through packet sizes? I truly wonder if it's just > for small and large packets that we see packet drops, or if it's somethin= g > repetitive throughout the range as well. > > for size in $(seq 0 1476); do if ping 10.0.0.56 -s $size -W 1 -c 1 -q >/d= ev/null; then echo "$((size + 42)): OK"; else echo "$((size + 42)): NOK"; f= i; done The weird thing is that if I remove the __skb_put_padto() call, ping doesn't work at all. Somehow the packets are corrupted, because they sure get out of the switch and I can see them arriving with tcpdump on the host. root@OpenWrt:/# for size in $(seq 0 1476); do if ping 192.168.1.137 -s $siz= e -W 1 -c 1 -q >/dev/null; then echo "$((size + 42)): OK"; else echo "$((size + = 42)): NOK"; fi; done 42: NOK 43: NOK 44: NOK 45: NOK 46: NOK 47: NOK 48: NOK 49: NOK 50: NOK 51: NOK (...) 1509: NOK 1510: NOK 1511: NOK 1512: NOK 1513: NOK 1514: NOK 1515: NOK 1516: NOK 1517: NOK 1518: NOK This of course make no sense, since the padding function should do nothing when the packet is bigger than 60 bytes. So what we are seeing is some kind of side effect from the usage of __skb_put_padto() I suppose? But I have no idea what that is, I looked at the function and what it calls down to __skb_pad(). I'm testing skb_linearize(), which seems to be called on this path... TCPdump on the host looks like this: # tcpdump -i enp7s0 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 by= tes 23:28:55.184019 IP _gateway > fedora: ICMP echo request, id 2461, seq 0, length 27 23:28:56.205294 IP _gateway > fedora: ICMP echo request, id 2462, seq 0, length 28 23:28:57.226495 IP _gateway > fedora: ICMP echo request, id 2463, seq 0, length 29 23:28:58.248013 IP _gateway > fedora: ICMP echo request, id 2464, seq 0, length 30 23:28:59.269157 IP _gateway > fedora: ICMP echo request, id 2465, seq 0, length 31 23:29:00.290443 IP _gateway > fedora: ICMP echo request, id 2466, seq 0, length 32 23:29:01.698700 IP _gateway > fedora: ICMP echo request, id 2467, seq 0, length 33 23:29:02.332131 IP _gateway > fedora: ICMP echo request, id 2468, seq 0, length 34 23:29:03.352442 IP _gateway > fedora: ICMP echo request, id 2469, seq 0, length 35 (...) 23:53:33.834706 IP _gateway > fedora: ICMP echo request, id 4000, seq 0, length 1475 23:53:34.854946 IP _gateway > fedora: ICMP echo request, id 4001, seq 0, length 1476 23:53:36.258777 IP truncated-ip - 1 bytes missing! _gateway > fedora: ICMP echo request, id 4002, seq 0, length 1477 23:53:36.896654 IP truncated-ip - 2 bytes missing! _gateway > fedora: ICMP echo request, id 4003, seq 0, length 1478 23:53:37.918022 IP truncated-ip - 3 bytes missing! _gateway > fedora: ICMP echo request, id 4004, seq 0, length 1479 23:53:38.938355 IP truncated-ip - 4 bytes missing! _gateway > fedora: ICMP echo request, id 4005, seq 0, length 1480 23:53:39.958451 IP truncated-ip - 4 bytes missing! _gateway > fedora: ICMP echo request, id 4006, seq 0, length 1480 23:53:40.978598 IP truncated-ip - 4 bytes missing! _gateway > fedora: ICMP echo request, id 4007, seq 0, length 1480 23:53:41.998991 IP truncated-ip - 4 bytes missing! _gateway > fedora: ICMP echo request, id 4008, seq 0, length 1480 23:53:43.020309 IP truncated-ip - 4 bytes missing! _gateway > fedora: ICMP echo request, id 4010, seq 0, length 1480 Here you can incidentally also see what happens if we don't pad the big pac= kets: the packet gets truncated. Yours, Linus Walleij