From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
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>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dsa: tag_rtl4_a: Bump min packet size
Date: Sat, 28 Oct 2023 01:03:47 +0200 [thread overview]
Message-ID: <3ffe7ea1-4dfb-4db8-a2ce-67733a190138@lunn.ch> (raw)
In-Reply-To: <95f324af-88de-4692-966f-588287305e09@gmail.com>
On Fri, Oct 27, 2023 at 02:23:13PM -0700, Florian Fainelli wrote:
> You would want your subject to be:
>
> net: dsa: tag_rtl4_a: Bump min packet size
>
> On 10/27/23 13:21, Linus Walleij wrote:
> > 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 sometimes, but not always, small packets are
> > dropped by the switch for no reason.
>
> And we are positive that the Ethernet MAC is also properly padding frames
> before having them ingress the switch?
It might be interesting to run a script which systematically does a
ping, or similar, for all frame sizes.
> > If we pad the ethernet frames to a minimum of ETH_FRAME_LEN + FCS
> > (1518 bytes) everything starts working fine.
>
> That is quite unprecedented, either the switch is very bogus or there is
> something else we do not fully understand...
It would also be interesting to know if the frames on the wire have
the padding removed when needed. Its not going to be good for
performance if a TCP ACK is 1500bytes in size, rather than the usual
~64.
Have problems also been noticed with traffic going from user port to
user port?
Andrew
next prev parent reply other threads:[~2023-10-27 23:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 20:21 [PATCH] dsa: tag_rtl4_a: Bump min packet size Linus Walleij
2023-10-27 21:23 ` Florian Fainelli
2023-10-27 23:03 ` Andrew Lunn [this message]
2023-10-29 22:18 ` David Laight
2023-10-29 15:38 ` Linus Walleij
2023-10-29 17:35 ` Andrew Lunn
2023-10-30 12:51 ` Vladimir Oltean
2023-10-30 14:29 ` Linus Walleij
2023-10-30 14:32 ` Linus Walleij
2023-10-28 22:04 ` Vladimir Oltean
2023-10-29 22:15 ` Linus Walleij
2023-10-29 23:00 ` Andrew Lunn
2023-10-30 7:39 ` 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=3ffe7ea1-4dfb-4db8-a2ce-67733a190138@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox