From: Lukasz Majewski <lukma@denx.de>
To: Andrew Lunn <andrew@lunn.ch>,
Alexander Duyck <alexander.duyck@gmail.com>
Cc: Vladimir Oltean <olteanv@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] dsa: marvell: Provide per device information about max frame size
Date: Thu, 5 Jan 2023 11:37:12 +0100 [thread overview]
Message-ID: <20230105113712.2bf0d37b@wsk> (raw)
In-Reply-To: <20230103100251.08a5db46@wsk>
[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]
Hi Andrew, Alexander,
> Hi Andrew,
>
> > > @@ -3548,7 +3548,9 @@ static int mv88e6xxx_get_max_mtu(struct
> > > dsa_switch *ds, int port) if
> > > (chip->info->ops->port_set_jumbo_size) return 10240 -
> > > VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN; else if
> > > (chip->info->ops->set_max_frame_size)
> > > - return 1632 - VLAN_ETH_HLEN - EDSA_HLEN -
> > > ETH_FCS_LEN;
> > > + return (max_t(int, chip->info->max_frame_size,
> > > 1632)
> > > + - VLAN_ETH_HLEN - EDSA_HLEN -
> > > ETH_FCS_LEN); +
> > > return 1522 - VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN;
> > >
> >
> > I would also prefer if all this if/else logic is removed, and the
> > code simply returned chip->info->max_frame_size - VLAN_ETH_HLEN -
> > EDSA_HLEN - ETH_FCS_LEN;
> >
>
> So then the mv88e6xxx_get_max_mtu shall look like:
>
> WARN_ON_ONCE(!chip->info->max_frame_size)
>
> if (chip->info->ops->port_set_jumbo_size)
> ...
> else
> return chip->info->max_frame_size - VLAN_ETH_HLEN -
> EDSA_HLEN - ETH_FCS_LEN;
>
>
> Or shall I put WARN_ON_ONCE to the mv88e6xxx_probe() function?
>
>
> The above approach is contrary to one proposed by Alexander, who
> wanted to improve the defensive approach in this driver (to avoid
> situation where the max_frame_size callback is not defined and
> max_frame_size member of *_info struct is not added by developer).
>
> Which approach is the recommended one for this driver?
Is there any decision regarding the preferred approach to rewrite this
code?
>
> > > +++ b/drivers/net/dsa/mv88e6xxx/chip.h
> > > @@ -132,6 +132,7 @@ struct mv88e6xxx_info {
> > > unsigned int num_gpio;
> > > unsigned int max_vid;
> > > unsigned int max_sid;
> > > + unsigned int max_frame_size;
> >
> > It might be worth adding a comment here what this value actually
> > represents.
>
> Ok. I will add proper comment.
>
> > We don't want any mixups where the value already has the
> > frame checksum removed for example.
>
> Could you be more specific here about this use case?
>
> The max_frame_size is the maximal size of the ethernet frame for which
> the IC designer provided specified amount of RAM (it is a different
> value for different SoCs in the Link Street family).
>
> >
> > Andrew
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-01-05 10:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-02 15:02 [PATCH v3 1/3] dsa: marvell: Provide per device information about max frame size Lukasz Majewski
2023-01-02 15:02 ` [PATCH v3 2/3] net: dsa: mv88e6xxx: add support for MV88E6020 switch Lukasz Majewski
2023-01-02 20:00 ` Andrew Lunn
2023-01-03 8:46 ` Lukasz Majewski
2023-01-02 15:02 ` [PATCH v3 3/3] net: dsa: mv88e6xxx: add support for MV88E6071 switch Lukasz Majewski
2023-01-02 19:58 ` [PATCH v3 1/3] dsa: marvell: Provide per device information about max frame size Andrew Lunn
2023-01-02 20:29 ` Andrew Lunn
2023-01-03 9:02 ` Lukasz Majewski
2023-01-03 12:54 ` Andrew Lunn
2023-01-05 10:37 ` Lukasz Majewski [this message]
2023-01-05 16:13 ` Alexander Duyck
2023-01-05 17:44 ` Lukasz Majewski
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=20230105113712.2bf0d37b@wsk \
--to=lukma@denx.de \
--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=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.