Re: [PATCH 1/7] dsa: marvell: Provide per device information about max frame size

Andrew Lunn
2023-03-10T16:17:43Z

On Fri, Mar 10, 2023 at 05:45:11PM +0200, Vladimir Oltean wrote:
> On Fri, Mar 10, 2023 at 02:17:19PM +0100, Lukasz Majewski wrote:
> > This is the "patch 4" in the comment sent by Russel (to fix stuff which
> > is already broken, but it has been visible after running the validation
> > code):
> >
> > https://lists.openwall.net/netdev/2023/03/09/233
>
> Ok, so nope, what I was talking about here (MTU 1492) is *not* what you
> have discussed with Russell in patch 4.
>
> What I was talking about is this:
> https://patchwork.kernel.org/project/netdevbpf/patch/20230309125421.3900962-2-lukma@denx.de/#25245979
> and Russell now seems to agree with me that it should be addressed
> separately, and prior to the extra development work done here.
>
> It looks like it will also need a bit of assistance from Andrew to
> untangle whether EDSA_HLEN should be included in the max_mtu calculations
> for some switch families only, rather than for all.

That is hard to say. From other peoples experiments, it seems like
some families don't impose the frame length check on DSA and CPU
ports. Hence they accept frames with DSA or EDSA headers, even if that
puts them over the theoretical port max. Other families do seem to
perform check on DSA and CPU ports. I don't think the datasheets say
anything about this.

The safe thing to do is:

Assume all switches can accept the standard minimum MTU + DSA/EDSA
headers on their CPU ports.

For those switches which accept frames bigger than the standard,
assume the DSA/EDSA header is counted as part of the limit, and so
adjust the calculation.

This might short change a few switches 4/8 bytes, but that is better
than being broken because frames are dropped.

Andrew