[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <11cf3d6f-91fc-41bb-b780-1d967f388981@lunn.ch>
Date: Sat, 4 Nov 2023 15:36:58 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Hans Ulli Kroll <ulli.kroll@...glemail.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Michał Mirosław <mirq-linux@...e.qmqm.pl>,
Vladimir Oltean <olteanv@...il.com>,
linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 1/4] net: ethernet: cortina: Fix MTU max setting
> + if (mtu > MTU_SIZE_BIT_MASK) {
> + netdev_err(netdev, "%s: MTU too big, max size 2047 bytes, capped\n", __func__);
> + mtu = MTU_SIZE_BIT_MASK;
> + }
So this should not actually happen. If it does, some protocol above is
ignoring the MTU. And if that happens, you are going to spam the log
at line rate.
Packets which are truncated are also pretty useless. They are likely
to be dropped by the receiver when the CRC fails. So i would suggest
drop them here, and increment a counter.
> #define SOF_EOF_BIT_MASK 0x3fffffff
> -#define SOF_BIT 0x80000000
> -#define EOF_BIT 0x40000000
> -#define EOFIE_BIT BIT(29)
> -#define MTU_SIZE_BIT_MASK 0x1fff
> +#define SOF_BIT BIT(31) /* Start of Frame */
> +#define EOF_BIT BIT(30) /* End of Frame */
> +#define EOFIE_BIT BIT(29) /* End of Frame Interrupt Enable */
> +#define MTU_SIZE_BIT_MASK 0x7ff /* Max MTU 2047 bytes */
Apart from the MTU_SIZE_BIT_MASK, this looks mostly unrelated.
Andrew
---
pw-bot: cr
Powered by blists - more mailing lists