• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 101 subscribers
  • Views 411 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: Occasionally Broadcast Packet Receive Problem for Multiple PRU Ethernet Ports

Kevin Peng
Expert 3762 points
Part Number: AM6442

Hi TI Experts,

Customer is working on AM64x SDK 09_02_01_09.

As we know we already support TSN in PRU shown below.

We found that for the multiple PRU ethernet ports connected situation, there is possibility that the broaIdcast packet will loss.

For example, if we connect eth0 & eth1, the ip address of eth0 and eth1 is shown below.

Then, we use PC to send the broadcast packet shown below.

In the normal situations, their testing code will print eth1 continuously shown below. 

We use wireshark to catch the corresponding IP igmp packet shown below, and could confirm that the IP of this packet belongs to eth1.

In the unexpected situations, their same testing code will print eth1 continuously shown below.

We use wireshark to catch the corresponding IP igmp packet shown below, but we found that the IP of this packet belongs to eth0.

In summary, there is possibility that the broadcast packet will loss in PRU multiple ethernet ports.

Could you help provide some suggestions for this problem please?

Thanks a lot!

Kevin

  • 0
    TI__Genius 16005 points

    Hi Kevin,

    First, a couple of clarification questions:

    1. Are both eth0 and eth1 added to the multicast group that is undertest?

    2. Under what conditions do the unexpected situations occur? What conditions count as normal conditions?

    From a general ethernet perspective, when two ports (not configured as a switch) are on the same subnet, usually eth0 (not eth1) would respond to any ICMP messages even if eth1 interface was specified. This is the case for CPSW ethernet (two external ports, one internal port, and single driver controlling both external ports). I'm currently not sure if 1. pru_icssg ethernet would have the same subnet issue and 2. whether the fact that multicasting is used here changes the behavior. 

    -Daolin

  • 0 in reply to Daolin Qiu
    TI__Expert 3762 points

    Hi Daolin,

    Thanks for your reply!

    We currently still not find out the exact condition that could cause the above mentioned unexpected situations. Generally it is just a small possibility that the unexpected situations will occur.

    Another more important thing is that customer is requiring to support TSN on all of the ethernet ports in AM64x (2 from CPSW, 3 from PRU). However, we found some features of TSN in PRU ethernet ports are not supported including FQTSS/CBS. Do you know if we have a plan to support these features for PRU ethernet ports?

    Thanks a lot!

    Kevin

  • +1 in reply to Kevin Peng
    TI__Genius 16005 points

    Hi Kevin,

    As mentioned in my email 

    Could you try

    1. Isolate eth1 as the only multicast destination (exclude eth0 from the multicast group) and verify that only eth1 (not eth0) responds to the multicast message?
    2. Isolate eth0 as the only multicast destination (exclude eth1 from the multicast group) and verify that only eth0 (not eth1) responds to the multicast message?

    This is to try some experiments to verify only expected the eth interfaces responds to the multicast messages.

    Additionally, is eth0 in promiscuous mode? Another behavior I have seen is when an interface is in promiscuous mode, even if it isn’t part of the multicast filter/group, it will receive multicast messages.

    Kevin Peng said:
    However, we found some features of TSN in PRU ethernet ports are not supported including FQTSS/CBS

    Is this finding the result of testing out FQTSS/CBS on the PRU ethernet ports or just through reading the SDK documentation? I noticed that https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html?highlight=tsn#time-senstive-network-tsn-offload-support indicates there is offload support for IET and EST but no indication to whether FQTSS/CBS is offloaded. This does not seem to say we don't support FQTSS/CBS on PRU ethernet just that it's not offloaded.

    I'm checking with the internal team about this feature and will get back to you with an update next week.

    -Daolin

  • +1 in reply to Daolin Qiu
    TI__Mastermind 27050 points
    Daolin Qiu said:
    Kevin Peng said:
    However, we found some features of TSN in PRU ethernet ports are not supported including FQTSS/CBS

    Is this finding the result of testing out FQTSS/CBS on the PRU ethernet ports or just through reading the SDK documentation? I noticed that https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/latest/exports/docs/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/PRU_ICSSG_Ethernet.html?highlight=tsn#time-senstive-network-tsn-offload-support indicates there is offload support for IET and EST but no indication to whether FQTSS/CBS is offloaded. This does not seem to say we don't support FQTSS/CBS on PRU ethernet just that it's not offloaded.

    Correct, ICSSG based Ethernet does not support FQTSS/CBS/802.1Qav. There are no plans to add this to ICSSG, use CPSW based Ethernet for Ethernet AVB.

    Daolin Qiu said:
    two ports (not configured as a switch) are on the same subnet,

    I noticed this as well. eth0 and eth1 are on the same subnet 192.168.13.x mask /24 from the same Linux instance and one networking stack. This is not something that should be generally done and how does a broadcast in this case behave is not clear.

      Pekka