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:

quoted

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