From: Vladimir Oltean <olteanv@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Lukasz Majewski <lukma@denx.de>, Andrew Lunn <andrew@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexander Duyck <alexander.duyck@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] dsa: marvell: Provide per device information about max frame size
Date: Fri, 10 Mar 2023 15:04:46 +0200 [thread overview]
Message-ID: <20230310130446.ltgtqpqpn4cboyfb@skbuf> (raw)
In-Reply-To: <ZAsh12DdwDfKUW8F@shell.armlinux.org.uk>
On Fri, Mar 10, 2023 at 12:25:59PM +0000, Russell King (Oracle) wrote:
> This is similar analysis to what I did for a previous patch set, and
> came to the conclusion that we need code in the driver to validate
> that the addition of these values is in fact correct. See my previous
> reviews and my recommendations on how to structure these patch sets,
> so we as reviewers don't _have_ to go to this level of verification.
Ok, I haven't read other patches or comments except for 1/7 yet.
> > I guess I will have to fix this now, since you haven't done it.
>
> I'm sorry, but why is this Lukasz's problem to fix? If it's broken today
> when using mv88e6xxx with this PHY, and Lukasz doesn't have this PHY,
> why does Lukasz have to solve this?
Well, in principle no one has to solve it. It would be good to not move
around broken code if we know it's broken, is what I'm saying. This is
because eventually, someone who *is* affected *will* want to fix it, and
that fix will conflict with the refactoring. Lukasz would have had the
interest in fixing it because he's touching that code. Again, I will do
this when I find the time.
> > > + /* Max Frame Size.
> > > + * This value corresponds to the memory allocated in switch internal
> > > + * memory to store single frame.
> > > + */
> >
> > What is the source of this definition?
> >
> > I'm asking because I know of other switches where the internal memory
> > allocation scheme has nothing to do with the frame size. Instead, there
> > are SRAM cells of fixed and small size (say 60 octets) chained together.
>
> The switch documentation only really talks about maximum frame sizes
> that the switch can handle, with a few bits that configure what the
> maximum frame size is. We also know how large the SRAM is, but how
> the SRAM is allocated to packets is for Marvell engineers to know
> and not us mere mortals.
>
> So, the base definition for this is the information provided in the
> switch documentation.
Agree with the "mere mortals" comment. I was trying to suggest that the
given definition tries to make it appear that we know more about the
switch internal memory allocation than we really do. "This value
corresponds to the memory allocated in switch internal memory to store
single frame" -> how do we know that it corresponds?
next prev parent reply other threads:[~2023-03-10 13:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-09 12:54 [PATCH 0/7] dsa: marvell: Add support for mv88e6071 and 6020 switches Lukasz Majewski
2023-03-09 12:54 ` [PATCH 1/7] dsa: marvell: Provide per device information about max frame size Lukasz Majewski
2023-03-10 12:02 ` Vladimir Oltean
2023-03-10 12:25 ` Russell King (Oracle)
2023-03-10 13:04 ` Vladimir Oltean [this message]
2023-03-10 13:06 ` Vladimir Oltean
2023-03-10 13:17 ` Lukasz Majewski
2023-03-10 13:36 ` Vladimir Oltean
2023-03-10 14:10 ` Lukasz Majewski
2023-03-10 15:45 ` Vladimir Oltean
2023-03-10 16:12 ` Andrew Lunn
2023-03-12 15:55 ` Lukasz Majewski
2023-03-13 15:01 ` Vladimir Oltean
2023-03-10 14:04 ` Russell King (Oracle)
2023-03-09 12:54 ` [PATCH 2/7] net: dsa: mv88e6xxx: add support for MV88E6020 switch Lukasz Majewski
2023-03-10 14:23 ` Vladimir Oltean
2023-03-09 12:54 ` [PATCH 3/7] net: dsa: mv88e6xxx: add support for MV88E6071 switch Lukasz Majewski
2023-03-09 12:54 ` [PATCH 4/7] dsa: marvell: Define .set_max_frame_size() function for mv88e6250 SoC family Lukasz Majewski
2023-03-09 12:54 ` [PATCH 5/7] dsa: marvell: Add helper function to validate the max_frame_size variable Lukasz Majewski
2023-03-09 13:21 ` Russell King (Oracle)
2023-03-09 13:26 ` Russell King (Oracle)
2023-03-09 13:47 ` Lukasz Majewski
2023-03-09 13:52 ` Vladimir Oltean
2023-03-09 13:57 ` Lukasz Majewski
2023-03-09 12:54 ` [PATCH 6/7] dsa: marvell: Correct value of max_frame_size variable after validation Lukasz Majewski
2023-03-09 14:05 ` Russell King (Oracle)
2023-03-09 14:43 ` Lukasz Majewski
2023-03-09 15:31 ` Russell King (Oracle)
2023-03-10 9:47 ` Lukasz Majewski
2023-03-09 15:42 ` Andrew Lunn
2023-03-10 11:53 ` Lukasz Majewski
2023-03-10 12:06 ` Russell King (Oracle)
2023-03-10 13:19 ` Lukasz Majewski
2023-03-10 15:25 ` Vladimir Oltean
2023-03-09 12:54 ` [PATCH 7/7] dsa: marvell: Modify get max MTU callback to use per switch provided value Lukasz Majewski
2023-04-03 11:55 ` [PATCH 0/7] dsa: marvell: Add support for mv88e6071 and 6020 switches Vladimir Oltean
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=20230310130446.ltgtqpqpn4cboyfb@skbuf \
--to=olteanv@gmail.com \
--cc=alexander.duyck@gmail.com \
--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=linux@armlinux.org.uk \
--cc=lukma@denx.de \
--cc=netdev@vger.kernel.org \
--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