--lcores: what it does and does not do

[Stephen Hemminger]

On Sat, 30 Mar 2024 12:06:15 -0400
fwefew 4t4tg <7532yahoo at gmail.com> wrote:

> I've made a DPDK test program that does the following on the same machine
> and for the same NIC. This is a test; it does nothing practical:
> 
> * Creates 1 RX queue then reads and pretty prints contents in a loop
> * Creates 1 TX queue then sends packets to a hardcoded IP address in a loop
> 
> When I run this program I include the command line arguments
> "--lcores=(0)@1,(1)@2" which is passed to 'rte_eal_init'.
> 
> This means there's a lcore identified '0' run on CPU HW core 1, and lcore
> '1' run on CPU HW core 2.
> 
> As I understand it, the intent of the lcores argument is that this test
> program will eventually run the RX loop as lcore 0, and the TX loop as
> lcore 1 (or vice-versa).
> 
> On the other hand after all the required DPDK setup is done --- memzones,
> mempools, queues, NIC devices initialized and started --- here's what DPDK
> has not done:
> 
> * It hasn't started an application thread for lcore 0 or lcore 1
> * DPDK doesn't know the function entry point for either loop so no loops
> are running.
> 
> Which is totally fine ... DPDK isn't magic. If the application programmer
> wants a RX and TX application thread pinned to some CPU, it should create
> the threads, set the CPU affinity, and run the loop in the NUMA aligned
> way. This is trivial to do. That is, with the required DPDK setup done, all
> that's left is to do this trivial work ... and the test program is up and
> running: problem solved.
> 
> The --lcores doesn't and cannot do this application work. So what is the
> practical result of it? What does it do?

Did your application every start the other threads with DPDK?
It is not recommended for applications to manage their own threads.
Possible but hard to get right.

A typical application looks like:


main() {
    // do some initialization
    rte_eal_init()

    // do more initialization that has to be done in main thread

    rte_eal_mp_remote_launch(worker_func, arg, CALL_MAIN);

    // main thread worker_func has exited, wait for others
    rte_eal_mp_wait_lcore()

    // back to single main thread
    rte_eal_cleanup()
}