From: Vladimir Oltean <olteanv@gmail.com>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH 1/4] drivers: net: dsa: qca8k: drop MTU tracking from qca8k_priv
Date: Thu, 24 Mar 2022 23:05:08 +0200 [thread overview]
Message-ID: <20220324210508.doj7fsjn3ihronnx@skbuf> (raw)
In-Reply-To: <YjzYK3oDDclLRmm2@Ansuel-xps.localdomain>
On Thu, Mar 24, 2022 at 09:44:27PM +0100, Ansuel Smith wrote:
> On Thu, Mar 24, 2022 at 12:45:24PM +0200, Vladimir Oltean wrote:
> > You need the max MTU.
> >
> > Why calculate it again? Why don't you do what mt7530 does, which has a
> > similar restriction, and just program the hardware when the CPU port MTU
> > is updated?
> >
>
> I just checked and wow it was that easy...
> Also wonder if I should add some check for jumbo frame... (I should
> check what is the max MTU for the switch and if it can accept jumbo
> frame+fcs+l2)
I'm not following you, sorry. What is your definition of "jumbo frame",
and what check is there to add?
> Wonder if I should propose a change for stmmac and just drop the
> interface and restart it when the change is down.
In the case of stmmac, dev->mtu is considered from stmmac_fix_features()
and from init_dma_rx_desc_rings(), so yes, putting the interface down
before updating the MTU and the device features, and then putting it
back up if it was previously up, should do the trick. Other drivers like
gianfar and many others do this too.
next prev parent reply other threads:[~2022-03-24 21:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 1:45 [net-next PATCH 0/4] Reduce qca8k_priv space usage Ansuel Smith
2022-03-22 1:45 ` [net-next PATCH 1/4] drivers: net: dsa: qca8k: drop MTU tracking from qca8k_priv Ansuel Smith
2022-03-22 11:58 ` Vladimir Oltean
2022-03-22 13:38 ` Ansuel Smith
2022-03-22 13:55 ` Vladimir Oltean
2022-03-22 14:03 ` Ansuel Smith
2022-03-24 10:45 ` Vladimir Oltean
2022-03-24 20:44 ` Ansuel Smith
2022-03-24 21:05 ` Vladimir Oltean [this message]
2022-03-24 23:10 ` Ansuel Smith
2022-03-24 23:14 ` Vladimir Oltean
2022-03-24 23:24 ` Ansuel Smith
2022-03-22 1:45 ` [net-next PATCH 2/4] drivers: net: dsa: qca8k: drop port_sts " Ansuel Smith
2022-03-22 1:45 ` [net-next PATCH 3/4] drivers: net: dsa: qca8k: rework and simplify mdiobus logic Ansuel Smith
2022-03-22 1:45 ` [net-next PATCH 4/4] drivers: net: dsa: qca8k: drop dsa_switch_ops from qca8k_priv Ansuel Smith
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=20220324210508.doj7fsjn3ihronnx@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).