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.

TDA4VH-Q1: TDA4VH: Validation of EST under linux native driver

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Hi TI experts,

I am using the switch mode under TDA4VH native driver 0900 to test the EST(3.2.2.10.3.3.2.2. EST — Processor SDK Linux for J784s4 Documentation). The network topology is as follows:

The config of tda4vh(sender) is as foloows.

Then I used the plget to test the EST and could get the expected results. 

But if I changed the command TC in the config about the tda4vh(sender), the priority 3 can't be trasmitted between them. 

   ---> 

I think that priority 3 packets will be mapped to TC2, and the above two commands about tc should logically not affect the communication of priority 3 packets. But as long as I follow the second tc command configuration, priority 3 packets cannot communicate.

Best Regards,
Lei

  • Hi Lei,

    But if I changed the command TC in the config about the tda4vh(sender), the priority 3 can't be trasmitted between them. 

    This is the intended behavior with your change right.

    As you are removing the gate entry for priority 3 traffic, you wouldn't see any priority 3 packets right? I think I do not understand what exactly is the issue here. Can you explain again.

    Regards,
    Tanmay

  • Hi Tanmay,

    The priority 3 is mapped to tc2 and tc2 is mapped to 'sched-entry S 4 300000'. If I don't add the 'sched-entry S 8 4000000', the prioritry 3 can't be transmitted.  Why can the 'sched-entry S 8 4000000' affect the priority 3? That measnif I use the following configuration, the priority 3 cant't be trasmitted.

    Best Regards,
    Lei

  • Hi Lei,

    I got the issue now.

    Why can the 'sched-entry S 8 4000000' affect the priority 3? 

    This should not happen. If this is happening, then that means that most likelypriority 3 traffic is going as some other priority in a queue which is not gated by CPSW.

    How exactly are you sending the priority 3 traffic? I cannot see any tc filters for mapping the traffic to any priority.

    Also can you crosscheck that the priority 3 traffic is being sent out or not with the CPSW statistics. As prio 3 is mapped to tc 2 which is mapped to queue 2, you should see increment in prio 2 packets in the CPSW statistics. You can see the statistics using "ethtool -S eth2".

    Regards,
    Tanmay

  • Hi Tanmay,

    How exactly are you sending the priority 3 traffic? I cannot see any tc filters for mapping the traffic to any priority.

    The vlan priority 3 is mapped to the tc2 by the 'tc map'. According to this tc command, we can get the following table. The first row of the table indicates the vlan id, the second row indicates the vlan priority, and the third row indicates the physical queues (starting from 1, there are 8 physical queues).

     
    vlan prio 0 1 2 3 4 5 6 7
    tc 0 0 1 2 0 0 0 0
    queue 1 1 1 2 3 1 1 1

    Then I used the plget to test the EST.

    Fullscreen
    1
    ./plget -i br0.4 -m pkt-gen -p 2 -t ptpl2 -n 200 -a 48:49:52:41:10:81 -l 80
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The statistic of the test:

    The priority of 2 is sent by the tx_pri2. But the priority of 2 should be mapped to the tc1 and the tc1 should be mapped to the queue 1 according to the '1@1" in the tc command. Then if I try to send the priority 3 through plget, these two tda4vh can't communicate. The priority 2 packets cannot be successfully received by another tda4vh either. I think, after sending a priority 3 packet, the network between them may be down.

    Best Regards,
    Lei

  • Hi Tanmay,

    I found that the kernel log reports error after I send the priority 3.

    Best Regards
    Lei

  • Hi Lei,

    Sorry for the delay.

    Is this issue still observed?

    Regards,
    Tanmay