From: Linus Walleij <linus.walleij@linaro.org>
To: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>
Subject: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
Date: Mon, 30 Oct 2023 10:26:50 +0100 [thread overview]
Message-ID: <20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org> (raw)
It was reported that the "LuCI" web UI was not working properly
with a device using the RTL8366RB switch. Disabling the egress
port tagging code made the switch work again, but this is not
a good solution as we want to be able to direct traffic to a
certain port.
It turns out that packets between 1496 and 1500 bytes are
dropped unless padded out to 1518 bytes.
If we pad the ethernet frames to a minimum of ETH_FRAME_LEN + FCS
(1518 bytes) everything starts working fine.
1496 is the size of a normal data frame minus the internal DSA
tag. The number is intuitive, the explanation evades me.
As we completely lack datasheet or any insight into how this
switch works, this trial-and-error solution is the best we
can do. FWIW this bug may very well be the reason why Realteks
code drops are not using CPU tagging. The vendor routers using
this switch are all hardwired to disable CPU tagging and all
packets are pushed to all ports on TX. This is also the case
in the old OpenWrt driver, derived from the vendor code drops.
I have tested smaller sizes, only 1518 or bigger padding works.
Modifying the MTU on the switch (one setting affecting all
ports) has no effect.
Before this patch:
PING 192.168.1.1 (192.168.1.1) 1470(1498) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1048ms
PING 192.168.1.1 (192.168.1.1) 1472(1500) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11267ms
After this patch:
PING 192.168.1.1 (192.168.1.1) 1470(1498) bytes of data.
1478 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.533 ms
1478 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.630 ms
PING 192.168.1.1 (192.168.1.1) 1472(1500) bytes of data.
1480 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.527 ms
1480 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.562 ms
Also LuCI starts working with the 1500 bytes frames it produces
from the HTTP server.
Fixes: 9eb8bc593a5e ("net: dsa: tag_rtl4_a: fix egress tags")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v2:
- Pad packages >= 1496 bytes after some further tests
- Use more to-the-point description
- Provide ping results in the commit message
- Link to v1: https://lore.kernel.org/r/20231027-fix-rtl8366rb-v1-1-d565d905535a@linaro.org
---
net/dsa/tag_rtl4_a.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/dsa/tag_rtl4_a.c b/net/dsa/tag_rtl4_a.c
index c327314b95e3..3292bc49b158 100644
--- a/net/dsa/tag_rtl4_a.c
+++ b/net/dsa/tag_rtl4_a.c
@@ -45,6 +45,16 @@ static struct sk_buff *rtl4a_tag_xmit(struct sk_buff *skb,
if (unlikely(__skb_put_padto(skb, ETH_ZLEN, false)))
return NULL;
+ /* Packets over 1496 bytes get dropped unless they get padded
+ * out to 1518 bytes. 1496 is ETH_DATA_LEN - tag which is hardly
+ * a coinicidence, and 1518 is ETH_FRAME_LEN + FCS so we define
+ * the threshold size and padding like this.
+ */
+ if (skb->len >= (ETH_DATA_LEN - RTL4_A_HDR_LEN)) {
+ if (unlikely(__skb_put_padto(skb, ETH_FRAME_LEN + ETH_FCS_LEN, false)))
+ return NULL;
+ }
+
netdev_dbg(dev, "add realtek tag to package to port %d\n",
dp->index);
skb_push(skb, RTL4_A_HDR_LEN);
---
base-commit: d9e164e4199bc465b3540d5fe3ffc8a9a4fc6157
change-id: 20231027-fix-rtl8366rb-e752bd5901ca
Best regards,
--
Linus Walleij <linus.walleij@linaro.org>
next reply other threads:[~2023-10-30 9:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 9:26 Linus Walleij [this message]
2023-10-30 14:16 ` [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size Vladimir Oltean
2023-10-30 14:37 ` Linus Walleij
2023-10-30 15:23 ` Vladimir Oltean
2023-10-30 15:30 ` Vladimir Oltean
2023-10-31 21:22 ` Linus Walleij
2023-11-02 10:48 ` Vladimir Oltean
2023-10-30 21:50 ` Linus Walleij
2023-10-30 22:20 ` Vladimir Oltean
2023-10-30 22:57 ` Linus Walleij
2023-10-30 23:09 ` Vladimir Oltean
2023-10-30 23:11 ` Linus Walleij
2023-10-31 0:37 ` Andrew Lunn
2023-10-31 3:37 ` Florian Fainelli
2023-10-31 14:06 ` Linus Walleij
2023-10-31 16:23 ` Florian Fainelli
2023-10-30 23:33 ` Vladimir Oltean
2023-10-31 14:16 ` Linus Walleij
2023-10-31 16:34 ` Vladimir Oltean
2023-10-31 19:02 ` Linus Walleij
2023-11-02 12:32 ` Vladimir Oltean
2023-10-31 19:18 ` Luiz Angelo Daros de Luca
2023-10-31 19:27 ` Linus Walleij
2023-11-01 12:35 ` Luiz Angelo Daros de Luca
2023-11-01 20:26 ` Linus Walleij
2023-11-02 10:04 ` Vladimir Oltean
2023-11-02 10:45 ` Vladimir Oltean
2023-11-03 17:05 ` Luiz Angelo Daros de Luca
2023-12-30 5:19 ` Luiz Angelo Daros de Luca
2023-12-30 12:28 ` Linus Walleij
2023-12-30 23:56 ` Luiz Angelo Daros de Luca
2023-11-02 10:31 ` Vladimir Oltean
2023-11-03 17:13 ` Luiz Angelo Daros de Luca
2023-10-31 22:44 ` Linus Walleij
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=20231030-fix-rtl8366rb-v2-1-e66e1ef7dbd2@linaro.org \
--to=linus.walleij@linaro.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.