AM6442: PRP offload firmware on Linux

Hello Maciej,

As mentioned in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1285569/am6442-hsr-prp-support-dependency-on-interface

HSR and PRP both work today in Linux. HSR has the option of having switching at layer 2 hardware in ICSSG using the forwarding offload. For PRP the only offload benefit will be duplicate drop, which should result in a CPU load saving at the endpoint. This is due to the PRP topology not requiring switching. The benefit of duplicate drop offload is not as significant as switching offload that HSR offload features. It may be possible to estimate the CPU load improvement by testing HSR with and without duplicate drop offload.

Because there is not much PRP duplicate drop offload benefit, PRP duplicate drop offload is currently not planned to be supported.

Maciej Kowalski said:

I found a demo that loads the PRP offload version via the R5 core

Currently we offer PRP operating at 100Mbps link speed on MCU+SDK for the R5 cores. In the perspective of MCU+SDK (RTOS) there is no distinction between offload vs nonoffload as the implementation we offer is already an "offload" version (no nonoffload version).

May I ask why your team is looking to run PRP offload on AM64x as opposed to HSR offload, which we already have support for and has the benefit of offloading switching?

-Daolin

Daolin Thank you for your response.

I understand that in the case of HSR, the topology is most often a ring, where HSR offloading handles not only duplicating the packet and sending it on two interfaces from the transmitter's perspective but also, from the node's perspective, forwarding the packet from one interface to another, which is likely costly. However, in both HSR and PRP, there is a need to copy the packet and send it on two separate interfaces from the transmitter's perspective.

I intended to check how much CPU A53 load we could save if we had the ability to offload the copying of transmitted packets to the PRU. In our device, we place a very high emphasis on reducing processor load.

Hi Maciej,

Maciej Kowalski said:

However, in both HSR and PRP, there is a need to copy the packet and send it on two separate interfaces from the transmitter's perspective.

From my knowledge at least on HSR offload, the following features are what are currently implemented for offload. (copied from https://docs.kernel.org/networking/netdev-features.html) 

• hsr-tag-ins-offload

This should be set for devices which insert an HSR (High-availability Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tag automatically.

• hsr-tag-rm-offload

This should be set for devices which remove HSR (High-availability Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tags automatically.

• hsr-fwd-offload

This should be set for devices which forward HSR (High-availability Seamless Redundancy) frames from one port to another in hardware.

• hsr-dup-offload

This should be set for devices which duplicate outgoing HSR (High-availability Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tags automatically frames in hardware.

I believe the hsr-dup-offload implements what you are asking about?

Maciej Kowalski said:

I intended to check how much CPU A53 load we could save if we had the ability to offload the copying of transmitted packets to the PRU

Daolin Qiu said:

It may be possible to estimate the CPU load improvement by testing HSR with and without duplicate drop offload

Since we currently only have HSR offload implemented you could try testing HSR offloaded for "hsr-dup-offload" specifically vs HSR non-offload to evaluate the CPU load improvement of offloading the copying of transmitted packets to the PRU.

Daolin Qiu said:

May I ask why your team is looking to run PRP offload on AM64x as opposed to HSR offload, which we already have support for and has the benefit of offloading switching?

Thanks for sharing the need reducing processor load! The intention of this question (quoted above) is specifically asking why you are targeting PRP topology instead of HSR topology?

-Daolin

Hello Maciej,

Daolin Qiu said:

Because there is not much PRP duplicate drop offload benefit, PRP duplicate drop offload is currently not planned to be supported.

I want to correct my previous statement on this. I just was informed by the internal team that PRP offload is planned to be released 1H 2025. This PRP offload feature will include "dup-offload", "tags-in-offload", and "tag-rm-offload".

If its possible for you to share, I'm still curious as to why you are targeting PRP topology instead of HSR topology?

-Daolin

Hello Maciej,

Additionally, I want to clarify the below.

Daolin Qiu said:

I want to correct my previous statement on this. I just was informed by the internal team that PRP offload is planned to be released 1H 2025.

This is most likely to implemented for RTOS rather than for RT-Linux. Are you planning on using RTOS or RT-Linux for this PRP use-case?

-Daolin