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.

TDA4VM: Use TSN's EST and IET features

Part Number: TDA4VM
Other Parts Discussed in Thread: TDA4VH

hello,

      I want to observe the phenomenon of the delay of the transmission delay of high priority packets after use the IET features.So I designed the following verification method.

first,I just enabled the TAS function,

#!/bin/sh
ifconfig eth1 down
ifconfig eth2 down

ifconfig eth3 down
ifconfig eth4 down


ethtool -L eth3 tx 2
ethtool --set-priv-flags eth3 p0-rx-ptype-rrobin off
# ethtool --set-priv-flags eth3 iet-frame-preemption on
# ethtool --set-priv-flags eth3 iet-mac-verify on
ifconfig eth3 up
sleep 5


tc qdisc replace dev eth3 parent root handle 100 taprio \
num_tc 2 \
map 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 \
queues 1@0 1@1 \
base-time 0 \
sched-entry S 1 100000 \
sched-entry S 2 5000 \
flags 2

tc -g class show dev eth3
tc qdisc add dev eth3 clsact
tc filter add dev eth3 egress protocol ip prio 1 u32 match ip dport 5002 0xffff action skbedit priority 2
tc filter add dev eth3 egress protocol ip prio 1 u32 match ip dport 5003 0xffff action skbedit priority 3
ip addr add 192.168.5.100 dev eth3
sleep 2

Then I sent a message from Port to 5003, and the results of the receiving end are as follows

Then I enabled the IET function at the same time in the two board cards and received the results of the same message as follows.

According to the above results, the EST function seems to be invalid。

I use SDK8.5,TDA4VH board as sender,using eth3. TDA4VH board as receiver,using eth0.

Also, I would like to ask is there any way to see the optimization brought by the IET characteristics?

  • Hi,

    If you are only sending port 5003 traffic, then IET will not come into play. IET will only occur if there are two different priority traffic trying to egress at the same time. So the EST schedule should not be affected due to this.

    Has the board been rebooted prior to enabling IET. I suggest that you should power-cycle the board before applying each configuration.

    Regards,
    Tanmay

  • hi,

    I have found the reason why EST fails,

    I designed the following EST schedule list,in order to be able to see IET phenomenon

    #!/bin/sh
    ifconfig eth1 down
    ifconfig eth2 down
    
    ifconfig eth3 down
    ifconfig eth4 down
    
    
    ethtool -L eth3 tx 3
    ethtool --set-priv-flags eth3 p0-rx-ptype-rrobin off
    ethtool --set-priv-flags eth3 iet-frame-preemption on
    ethtool --set-priv-flags eth3 iet-mac-verify on
    ifconfig eth3 up
    sleep 5
    
    
    tc qdisc replace dev eth3 parent root handle 100 taprio \
    num_tc 3 \
    map 0 0 1 2 0 0 0 0 0 0 0 0 0 0 0 0 \
    queues 1@0 1@1 1@2 \
    base-time 0 \
    sched-entry S 1 100000 \
    sched-entry S 2 5000 \
    sched-entry S 4 5000 \
    flags 2
    
    tc -g class show dev eth3
    tc qdisc add dev eth3 clsact
    tc filter add dev eth3 egress protocol ip prio 1 u32 match ip dport 5003 0xffff action skbedit pri
    
    tc filter add dev eth3 egress protocol ip prio 1 u32 match ip dport 5002 0xffff action skbedit pri
    ip addr add 192.168.5.100 dev eth3
    sleep 2
    

     

    in vm board, Run the following command

    ifconfig eth0 down
    ethtool -L eth0 tx 3
    ethtool --set-priv-flags eth0 p0-rx-ptype-rrobin off
    ethtool --set-priv-flags eth0 iet-frame-preemption on
    ethtool --set-priv-flags eth0 iet-mac-verify on
    ifconfig eth0 up

    Then send the following content on the sender

    ./plget -i eth3 -m pkt-gen -t udp -u 5002 -a 192.168.5.110 -n 128 -l 1500 &
    
    ./plget -i eth3 -m pkt-gen -t udp -u 5003 -a 192.168.5.110 -n 128 -l 64 &

    Because the 5002 traffic sends require 12us, I think the 5002 traffic will be preempt every time.

    Therefore, I can see that the receiving interval of 5002 will be greater than 200us and 5003 traffic will be less than 110us

    It can be seen that for the 5002 traffic above the picture, there is no time to appear more than 200us.

    In addition, if I continue to use EST according to this configuration, I do not use IET.

    I can think that the 5002 trafficwill definitely occupy the time of 5003 traffic, so the 5003 traffictime will often occur more than 200US, but the phenomenon does not appear。

  • Hi,

    You can see if the IET is in works or not by checking the output of "ethtool -S eth3 | grep iet" on the sender. It will have the number of packets fragmented or not. Also I believe that IET will only work with EST within one schedule and not across schedule.

    Regards,
    Tanmay

  • Also I believe that IET will only work with EST within one schedule and not across schedule.

    thanks,This has been very helpful to me.I will try again to see the effect of the iet function on high priority messages