mqprio map problem(TDA4)

The above configuration diagram is not correct, now provide the configuration screenshot again

Hello,

Please clarify which device you're using. The title of this thread has AM6442, but your screenshot shows j7-evm.

Thanks and regards,

Jianzhong

Please clarify what HW (TI EVM?, TDA4 or AM64x ?) and SW (SDK version) you are using. Slightly more which should apply regardless of AM64x or TDA4.

an jun said:

And we send data through iperf, and at the same time we send data through sockets in user space, Iperf commands are as follows

Are you expecting the locally generated traffic (your own program?) to preempt other (iperf3 ?) locally generated traffic? Preemption (IET) happens at the TX port, typical test is switched preemptable traffic (such as your iperf3 at 500Mbit/s max MTU) and locally injected express traffic, and the same at other switches in the LAN. For local SW generated traffic it is much harder to create a situation where a preemptable frame has only partially been sent and the express queue becomes non-empty.

What is your application goal? If you are trying to just demonstrate IET/preemption happening and counters increasing I would suggest a switch configuration, with interfering preemptable traffic going through the AM64x switch, and your application creating express traffic.

  Pekka

The board is TDA4

Thanks for confirmation. I'll loop in TDA4 team.

Hi, according to your reply, there is no problem in using iperf and TC filter test, but the problem in our test is that we send data packets from user space through socket 

tc-mqprio(8) - Linux manual page (man7.org)

Simply , if iperf is used to send data with destination port 5003, TX_PRI1's counter increases, but if socket (priority 3) is used to send data, TX_pri3's counter increases.According to the MQPRIO mapping, the TX_PRI1 counter should be increased and the iet_tx_frag counter should not be increased

1: ethtool -L eth1 tx 2

2：tc qdisc replace dev eth0 handle 100: parent root mqprio \
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 \
hw 0

If the above configuration is used, can data with priority 3 of the socket be mapped to Queue 1? According to your test instructions, iperf data of priority 3 can be mapped to hardware Queue 1. I think the two approaches should be consistent

Hi,

The priority 3 of socket application is actually mapped to queue 3. You will have to enable 4 queues for this at the minimum. You can then choose to useonly 2 queues by using the command I posted.

an jun said:

I think the two approaches should be consistent

The priorities in socket application in your case and iperf should be different. Is it possible for you to share your socket application code? That should clear things.

Do you have any constraints on enabling more than 2 queues?

Regards,
Tanmay

hi:

    The change you provided is not the result I expected, I expect the following results:

        1：pri3 map to tc 1  and  map Tx queue 1

        2:   pri0-2 and pri4-7 map to tc 0, and map Tx queue 0

      I may have been a little unclear, but let me describe my test in more detail:

        config:

             board A:

                  ifconfig eth0 down
                  ethtool -L eth0 tx 2
                  ethtool --set-priv-flags eth0 iet-frame-preemption on
                  ifconfig eth0 up

                  ifconfig eth0 192.168.100.10

                  tc qdisc replace dev eth0 handle 100: parent root mqprio 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 hw 0

                  tc qdisc add dev eth0 clsact

                  tc filter add dev eth0 egress protocol ip prio 1 u32 match ip dport 5002 0xffff action skbedit priority 2

             board B:

                 ifconfig eth0 down
                 ethtool -L eth0 tx 2
                  ethtool --set-priv-flags eth0 iet-frame-preemption on
                  ifconfig eth0 up

                  ifconfig eth0 192.168.100.10

             config result:

         I did the following  six tests,The results are as follows:

    Test 1:

                     Board A: iperf3 -c 192.168.100.20 -u -b500M -l1472 -t300 -p5002

              Board B:iperf3 -s -p5002

                    Check the result by running commands :
                    

                    conclusion: this is what I expect,   iperf map to tc 0, and map to tx Queue 0

Test 2:

          board A socket priorit set code:

int pri = 3;
setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &pri, sizeof(pri));

          Check the result by running commands :

              conclusion: this is not  what I expect,   socket data map to tc 1,But I'm not sure it's mapped to queue1 because tx_pri3 is growing

Test3:

              Check the result by running commands :

     conclusion: this is not  what I expect,   socket data map to tc 1,But I'm not sure it's mapped to queue1 because tx_pri3 is growing; iperf data map to tc 0, and map to Tx queue 0

Test 4:

      Board A socket priority set:

int pri = 2;
setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &pri, sizeof(pri));

      Check the result by running commands :

 conclusion: this is not  what I expect,   socket data map to tc 0,But I'm not sure it's mapped to queue0 because tx_pri2 is growing, and iet_tx_frag is growing ; iperf data map to tc 0, and map to Tx queue 0

    Assuming that socket data is mapped to Tx queue 0, why iet_tx_frag is growing?

Test 5:

   Board A socket priority set:

int pri = 4;
setsockopt(fd, SOL_SOCKET, SO_PRIORITY, &pri, sizeof(pri));

    Check the result by running commands :

conclusion: this is not  what I expect,   socket data map to tc 0,But I'm not sure it's mapped to queue0 because tx_pri4 is growing, and iet_tx_frag is growing ; iperf data map to tc 0, and map to Tx queue 0

   Assuming that socket data is mapped to Tx queue 0, why iet_tx_frag is growing?

Test 6: 

    Board A add filter:   

     tc filter add dev eth0 egress protocol ip prio 1 u32 match ip dport 5003 0xffff action skbedit priority 3

    Check the result by running commands :

I don't know that my understanding of this function is different from yours 

Thanks

@Tanmay Patil  can you help me,thanks

Hi,

Sorry for the delay.

The skbedit and tc priority are different from the priority you assign using the SO_PRIORITY option. The SO_PRIORITY option maps to the hardware queues directly. Where as the skbedit and tc priorities map to specific traffic classes which in turn map to hardware queues. So if you want to match both these, then you would have to map the tc priority and traffic classes one-to-one.

So, all your test results are correct and as I would have expected the mapping to behave.

an jun said:

    The change you provided is not the result I expected, I expect the following results:

        1：pri3 map to tc 1  and  map Tx queue 1

        2:   pri0-2 and pri4-7 map to tc 0, and map Tx queue 0

Hence, if you want this to work with both tc priority and SO_PRIORITY, then you would have to map priority 3 to tc 1 and to Tx queue 3. It won't be possible with Tx queue 1. The following configuration will work :

#!/bin/sh
 
ifconfig eth0 down
ifconfig eth1 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
ifconfig eth0 up
sleep 5
 
tc qdisc replace dev eth0 handle 100: parent root mqprio \
    num_tc 2 \
    map 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 \
    queues 1@0 1@3 \
    hw 0

Regards,
Tanmay

hi:

Okay, I see. I'll make time to test it again
But I still have a question:
if I open two TX queues (0 and 1, ethtool -L eth0 tx 2)
according to you, if I use the SO_PRIORITY attribute to send data with priority=3, then the data is mapped to queue3? Can Queue3 still send data？
thanks

Yes, queue 3 will still be able to send data then. This queue is hardware queue.

Regards,
Tanmay