How to simulate and check the TC-locking problem?

[hengqiali]

What method should I use to simulate the TC-locking situation?

[rchac]

You could create a non-MQ htb hierarchy, and attempt to pass >4Gbps traffic. Traffic will effectively bottleneck as it passes through one CPU core / tc qdisc lock. You should experience latency increases and throughput ceiling. As soon as you switch to MQ, with xdp-cpumap-tc enabled, it should permit greater throughput as htb leaf classes will be distributed among CPU cores / queues. To run xdp-cpumap-tc you would first run something like:

./xdp-cpumap-tc/bin/xps_setup.sh -d INTERFACE --default --disable
./xdp-cpumap-tc/src/xdp_iphash_to_cpu --dev INTERFACE --lan
./xdp-cpumap-tc/src/xdp_iphash_to_cpu_cmdline --clear
./xdp-cpumap-tc/src/tc_classify --dev-egress INTERFACE

corresponding to your shaped interface. It can be wan or lan. You can shape two interfaces if you want to shape both directions, just specify --lan in one command and --wan in another. Same with tc_classify command, do one for each interface.

Then create the MQ+HTB heirarchy following general idea from this project's file https://github.com/xdp-project/xdp-cpumap-tc/blob/master/bin/tc_mq_htb_setup_example.sh

You can modify the bash script to reflect your use case a little better. You can check out https://github.com/rchac/LibreQoS/blob/main/v0.9/LibreQoS.py to see how we did this using Python for LibreQoS.

[netoptimizer]

./xdp-cpumap-tc/bin/xps_setup.sh -d INTERFACE --default

I need to correct this!

• Above commend enables xps and we MUST disable xps for TC-BPF-program to have effect.
• As described in README

The correct command is

 ./xdp-cpumap-tc/bin/xps_setup.sh -d INTERFACE --default --disable

Notice the extra parameter --disable.
The script also support a --list parameter to inspect the current config.

[rchac]

I apologize for the mistake, thank you for pointing this out! I have edited both here and on LibreQoS to reflect this correction.

[netoptimizer]

I apologize for the mistake, thank you for pointing this out! I have edited both here and on LibreQoS to reflect this correction.

Thanks for editing and fixing the mistake.
I've updated the README in PR #6 to help others.