Re: [PATCH net-next 09/11] net: dsa: rzn1-a5psw: Add support for management port frame length adjustment

Lad, Prabhakar
2025-12-09T16:02:48Z

Hi Vladimir,

Thank you for the review. Sorry for the late reply.

On Fri, Nov 21, 2025 at 9:05 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Fri, Nov 21, 2025 at 11:35:35AM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Extend the RZN1 A5PSW driver to support SoC-specific adjustments to the
> > management (CPU) port frame length. Some SoCs, such as the RZ/T2H and
> > RZ/N2H, require additional headroom on the management port to account
> > for a special management tag added to frames. Without this adjustment,
> > frames may be incorrectly detected as oversized and subsequently
> > discarded.
> >
> > Introduce a new field, `management_port_frame_len_adj`, in
> > `struct a5psw_of_data` to represent this adjustment, and apply it in
> > `a5psw_port_change_mtu()` when configuring the frame length for the
> > CPU port.
> >
> > This change prepares the driver for use on RZ/T2H and RZ/N2H SoCs.
>
> In the next change you set this to 40. What's the reason behind such a
> high value (need to set the management port A5PSW_FRM_LENGTH value to
> 1574 bytes to pass L2 payload of 1500 bytes)? It sounds like this needs
> to be called out more clearly for what it is - a hardware bug.
>
Regarding the question about the relatively large adjustment value:
according to the hardware manual,
“Set the FRM_LENGTH register in port 3 (CPU port) to more than or
equal to the initial value. When you want to limit the frame length of
the received frame, use FRM_LENGTH registers in port 0 to port 2.”

In practice, with the default MTU (i.e. without applying the +40-byte
adjustment), RX traffic operates correctly. For example, running
iperf3 in reverse mode shows no issues, and frames are received
without errors. However, in the forward direction (TX from the CPU
port), throughput drops to zero and iperf3 fails.

When the MTU of the CPU-facing interface is increased (e.g. ip link
set lan0 mtu 1540), TX traffic immediately starts working correctly.
Likewise, increasing the FRM_LENGTH on the switch side for the CPU
port resolves the problem, which indicates that the frame length
configuration on this port is directly involved.

Given this behaviour, it appears that the management (CPU) port
requires additional headroom to successfully transmit frames, even
though RX succeeds without it. The STMMAC driver is used as the
controller driver for the management port, we are trying to determine
whether there is any known interaction, alignment constraint, or
undocumented overhead that would explain the need for this extra
margin.

Could you please advise on how to handle this issue?

Cheers,
Prabhakar