From: Simon Horman <simon.horman@corigine.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Luiz Angelo Daros de Luca <luizluca@gmail.com>,
netdev@vger.kernel.org, linus.walleij@linaro.org,
alsi@bang-olufsen.dk, andrew@lunn.ch, vivien.didelot@gmail.com,
f.fainelli@gmail.com, olteanv@gmail.com, davem@davemloft.net,
pabeni@redhat.com, robh+dt@kernel.org, krzk+dt@kernel.org,
arinc.unal@arinc9.com, Alexander Duyck <alexanderduyck@fb.com>
Subject: Re: [PATCH net-next v4] net: dsa: realtek: rtl8365mb: add change_mtu
Date: Thu, 9 Mar 2023 10:07:51 +0100 [thread overview]
Message-ID: <ZAmh54kNGDUEay3H@corigine.com> (raw)
In-Reply-To: <20230308224529.10674df1@kernel.org>
On Wed, Mar 08, 2023 at 10:45:29PM -0800, Jakub Kicinski wrote:
> On Wed, 8 Mar 2023 14:10:59 -0300 Luiz Angelo Daros de Luca wrote:
> > > Perhaps I am misreading this, perhaps it was discussed elsewhere (I did
> > > look), and perhaps it's not important. But prior to this
> > > patch a value of 1536 is used. Whereas with this patch the
> > > value, calculated in rtl8365mb_port_change_mtu, is
> > > ETH_DATA_LEN + VLAN_ETH_HLEN + ETH_FCS_LEN = 1500 + 18 + 4 = 1522.
> >
> > That value, as mentioned in the commit message, probably came from
> > rtl8366rb driver jumbo frame settings.
> > The "rtl8366rb family" has 4 levels of jumbo frame size:
> >
> > #define RTL8366RB_SGCR_MAX_LENGTH_1522 RTL8366RB_SGCR_MAX_LENGTH(0x0)
> > #define RTL8366RB_SGCR_MAX_LENGTH_1536 RTL8366RB_SGCR_MAX_LENGTH(0x1)
> > #define RTL8366RB_SGCR_MAX_LENGTH_1552 RTL8366RB_SGCR_MAX_LENGTH(0x2)
> > #define RTL8366RB_SGCR_MAX_LENGTH_16000 RTL8366RB_SGCR_MAX_LENGTH(0x3)
> >
> > The first one might be the sum you did. I don't know what 1536 and
> > 1552 are for. However, if those cases increase the MTU as well, the
> > code will handle it.
> > During my tests, changing those similar values or disabling jumbo
> > frames wasn't enough to change the switch behavior. As "rtl8365mb
> > family" can control frame size byte by byte, I believe it ignores the
> > old jumbo registers.
> >
> > The 1522 size is already in use by other drivers. If there is
> > something that requires more room without increasing the MTU, like
> > QinQ, we would need to add that extra length to the
> > rtl8365mb_port_change_mtu formula and not the initial value. If not,
> > the switch will have different frame limits when the user leaves the
> > default 1500 MTU or when it changes and reverts the MTU size.
>
> Could I trouble you for v5 with some form of this explanation in the
> commit message?
FWIIW, that would address my concern.
next prev parent reply other threads:[~2023-03-09 9:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 21:02 [PATCH net-next v4] net: dsa: realtek: rtl8365mb: add change_mtu Luiz Angelo Daros de Luca
2023-03-08 12:03 ` Simon Horman
2023-03-08 17:10 ` Luiz Angelo Daros de Luca
2023-03-09 6:45 ` Jakub Kicinski
2023-03-09 9:07 ` Simon Horman [this message]
2023-03-10 2:55 ` Luiz Angelo Daros de Luca
2023-03-10 6:29 ` Jakub Kicinski
2023-03-10 7:54 ` Simon Horman
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=ZAmh54kNGDUEay3H@corigine.com \
--to=simon.horman@corigine.com \
--cc=alexanderduyck@fb.com \
--cc=alsi@bang-olufsen.dk \
--cc=andrew@lunn.ch \
--cc=arinc.unal@arinc9.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=luizluca@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=vivien.didelot@gmail.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.