PROCESSOR-SDK-AM64X: The maximum MTU of HSR interface

Hello Milan,

Milan Stevanovic said:

However, after the process of inserting HSR tag is offloaded to the PRU firmware, the maximum MTU of the HSR interface can be restored to 1500. It seems this is not implemented in driver.

To clarify, are you saying that when HSR tag insertion is offloaded to the PRU, the expectation is that the max MTU of the HSR interface should remain 1500 (not be limited to 1494)?

Milan Stevanovic said:

Is there a reason why this is not implemented in linux driver? Could you provide some patch on this point?

My understanding is that the hsr_device.c is not something our team modifies as it is not a TI specific driver but rather code for Linux HSR in general (not specific to TI Ethernet). If there are any changes to account for this MTU size, I would think they would be in the icssg_prueth.c driver: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/icssg/icssg_prueth.c?h=ti-rt-linux-6.6.y. Upon an initial view into this driver, I don't specifically see anywhere where the MTU size is addressed. Let me check with the developer on this.

-Daolin

Hi Daolin,

yes it is correct about MTU size...

hsr_device.c is not TI specific but there is example where you need and you did modification...

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/net/hsr/hsr_device.c?h=11.00.09&id=e748d0fd66abc4b1c136022e4e053004fce2b792

probably modification is not complicated and we can do too...

But first we want to understand impact if we do not see some issues with this kind of modification.. If it is in your repository, it is easier for us to reuse, share and maintain... 

Hi Milan,

Milan Stevanovic said:

yes it is correct about MTU size...

Is there a particular reason for needing the HSR interface restored to 1500 for the case of HSR offloaded? In other words, is changing to 1500 a requirement for a specific function you are trying to test/implement?

Milan Stevanovic said:

probably modification is not complicated and we can do too...

But first we want to understand impact if we do not see some issues with this kind of modification.. If it is in your repository, it is easier for us to reuse, share and maintain... 

I'm trying to check with the team internally on the firmware side on how if the HSR tag insertion handles the MTU size restriction. I will let you know if I find out anything.

-Daolin

Hi Daolin,

The HSR comformance test requires the maximum frame length to supoort up to 1528 bytes(14-byte Ethernet header + 4-byte VLAN tag + 6-byte HSR tag + 1500-byte MTU + 4-byte FCS)

Hi Milan, 

Our Linux developer was out of office last week, he is planning on checking on this this week, I will update once I find out more information. Please kindly ping this thread again if I don't respond with an update by Thursday or Friday.

From the firmware side, the firmware developer has informed me that the firmware does not handle any length related checking when HSR tag insertion is offloaded to the PRU firmware.

-Daolin

Hi Milan, 

Apologies for the delay in response.

Milan Stevanovic said:

probably modification is not complicated and we can do too...

But first we want to understand impact if we do not see some issues with this kind of modification.. If it is in your repository, it is easier for us to reuse, share and maintain... 

From the Linux perspective, for both the offload and non-offload cases, we don't do any special modification of the MTU size from the driver side. Our developer has described "MTU for hsr device hsr0 is modified by the kernel stack in hsr_dev_change_mtu() which essntially makes MTU = 1500-6 = 1494. This happens during hsr_add_port()"

The main concern I can see with making a modification is from the firmware side there is no frame length related checking when the HSR tag insertion is offloaded to the firmware. So, if you restore the maximum MTU of the HSR interface to 1500B and the firmware inserts the 6 byte HSR tag, the total frame size will be 1506B so since there is no check in the firmware.

Milan Stevanovic said:

The HSR comformance test requires the maximum frame length to supoort up to 1528 bytes(14-byte Ethernet header + 4-byte VLAN tag + 6-byte HSR tag + 1500-byte MTU + 4-byte FCS)

This description of the maximum frame length seems to exclude the 6B HSR tag from the 1500B MTU? I'm not fully understanding if the HSR tag is counted towards the 1500B MTU or should not be part of the MTU... 

Milan Stevanovic said:

The kernel HSR subsystem limits the maximum MTU of the HSR interface to 1494, which is the maximum MTU(1500) minus the HSR tag length(6), this is because the HSR subsystem occupies part of the MTU when adding the HSR tag

Here, it was implied that the HSR tag occupies part of the MTU when adding the HSR tag...

-Daolin

Daolin:

The main concern I can see with making a modification is from the firmware side there is no frame length related checking when the HSR tag insertion is offloaded to the firmware. So, if you restore the maximum MTU of the HSR interface to 1500B and the firmware inserts the 6 byte HSR tag, the total frame size will be 1506B so since there is no check in the firmware.

MS: I think if you change kernel driver and check if there is offload, you can add these 6B.. Is it possible to check if HSR offload is configure in kernel driver and according this make decision to add or not 6B

Hi Milan, 

Milan Stevanovic said:

MS: I think if you change kernel driver and check if there is offload, you can add these 6B.. Is it possible to check if HSR offload is configure in kernel driver and according this make decision to add or not 6B

When you say "kernel driver", are you referencing the hsr_device.c https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/net/hsr/hsr_device.c?

Additionally, if I'm understanding you correctly, by "adding 6B" you mean not the actual HSR tag insertion but simply restoring the MTU size from 1494B to 1500B in this kernel driver? If so, I'm not sure how this addresses the concern that the total frame size being 1506B as seen by the firmware (because the firmware performs the actual HSR tag insertion when HSR is offloaded).

If what you mean by "adding 6B" is actually removing the HSR tag insertion from being performed by the firmware and simply having this kernel driver insert the HSR tag, this would no longer be a complete HSR offload (since HSR tag insertion would effectively not be offloaded to firmware). If this was what you meant, I think this could technically be achieved by ensuring that the "ethtool -K <eth inferface> hsr-tag-ins-offload off" and keeping everything else on in the HSR offload setup script in https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/HSR_Offload.html. However, the impact of doing this on the overall offload is less understood. 

-Daolin

Hi Daolin,

Idiea is inside HSR code of kernel  https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/net/hsr/hsr_device.c

In this HSR code in linux kernel, depend of HSR offload is on or off, MTU will be 1494 or 1500... we can check in our next call more details

Hi Milan, 

Milan Stevanovic said:

In this HSR code in linux kernel, depend of HSR offload is on or off, MTU will be 1494 or 1500... we can check in our next call more details

Daolin Qiu said:

The HSR comformance test requires the maximum frame length to supoort up to 1528 bytes(14-byte Ethernet header + 4-byte VLAN tag + 6-byte HSR tag + 1500-byte MTU + 4-byte FCS)

This description of the maximum frame length seems to exclude the 6B HSR tag from the 1500B MTU? I'm not fully understanding if the HSR tag is counted towards the 1500B MTU or should not be part of the MTU... 

Sure, if it's not currently very high in your priority list, we can talk more in the next call about this.

-Daolin