From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 05C4F43D7A for ; Sat, 30 Mar 2024 17:06:53 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 830964025E; Sat, 30 Mar 2024 17:06:53 +0100 (CET) Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by mails.dpdk.org (Postfix) with ESMTP id 02C784021D for ; Sat, 30 Mar 2024 17:06:52 +0100 (CET) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-614769887e6so3125047b3.1 for ; Sat, 30 Mar 2024 09:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711814811; x=1712419611; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=xRLr/7Ts2hpTd1ojj1q8NfJpFTOKyVt8U4CBeBSjQZ4=; b=UOf16kB6wkxKvjRtylAHx6MdnrvEtCdCP6Q4oVPW0dNtgHFHsPHZqNKrdArGbIPKVA QyC93iUOaTp7Q90/ET/VrlrymbBrXaY6Qb8w/ls2wLR4ooFrWTggDPTUPGfERT2fzlKi 8aGIPRWXas14n1pfJx8tJV90038+ZqVtnjgSQk1EncdJW4qppsr0w6RIufvNuOPSmlUq rCXxYzM5pZ1vZVpkqdfN86B38aNiwUIs9EY+RJQ9np9UDusn+aFct6aMEpNil577ergX RfkjaPiQR1IahKTwN12fcpJOxR00C2cRTgkZZzuRfL6AyuJPtFSD/h42ZXRTdtdbVhGX u7dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711814811; x=1712419611; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=xRLr/7Ts2hpTd1ojj1q8NfJpFTOKyVt8U4CBeBSjQZ4=; b=LT4ZbDs83bj9BxhqEy+HMA/7AyCse4ToxTKKuh6lkr4D9ARLIdkUrltI8Fip5djj7k FOm1yFh0YW3wwQoWTRouCphtJuNbJ7XrgmDdr+mMuMZanREBqeN7OoW5fSokQLihbf5h OkOFJUb3NDw/HOQ5yiVhGNlj04RJ9POizXKrUG+JIC8pxqYAxnZznfRUTtWtUB5R0fSa t7oaWm/kkk+creQhalrn9ubsRwwno+RlZDp8nGSdIgQxqa6Qo/7tyD6Bk7fqrvnHrTz4 3jw6qO2h1lYXTS7j3Af4z1O3pLP5hFIeOUfTOpe+unvC3jHR7BsI8g404P0RDdFOkcdc 9QDw== X-Gm-Message-State: AOJu0YynsKG9czRHI+odhmav4WQ4PbSPxOGk5V1Pieb+3NAjT8DUxUf6 i2BQg629u/hYG5F9klXXLNh2smHHpzoYhP5vRrt8m0LXRYBCwTWbjnHhP/3wbkDj6MZUZy6VS3t v/4JITOwbjAk20uY/932nr4uzWnSlL0ivZzw= X-Google-Smtp-Source: AGHT+IE3daPJGjNW2O/4qPwbDYEjQrZBx2ZwHVRQafjq/bk+GGVrOVLWBa0meM02kxGp485RnO1PTvHKtpyX3dHwdiA= X-Received: by 2002:a25:ea07:0:b0:dc6:e545:68be with SMTP id p7-20020a25ea07000000b00dc6e54568bemr5369108ybd.29.1711814810973; Sat, 30 Mar 2024 09:06:50 -0700 (PDT) MIME-Version: 1.0 From: fwefew 4t4tg <7532yahoo@gmail.com> Date: Sat, 30 Mar 2024 12:06:15 -0400 Message-ID: Subject: --lcores: what it does and does not do To: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000babc630614e2f1e8" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000babc630614e2f1e8 Content-Type: text/plain; charset="UTF-8" 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? --000000000000babc630614e2f1e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've made a DPDK test program that does the following on the same ma= chine and for the same NIC. This is a test; it does nothing practical:
<= br>* 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=3D(0)@1,(1)@2" whi= ch is passed to 'rte_eal_init'.=C2=A0

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 under= stand it, the intent of the lcores argument is that this test program will = eventually=C2=A0run the RX loop as lcore 0, and the TX loop as lcore 1 (or = vice-versa).=C2=A0

On the other hand after all the required DPDK setup is done --- memzo= nes, mempools, queues, NIC devices initialized and started --- here's w= hat DPDK has not done:

* It hasn't started an application thread for lcore 0 or lcor= e 1
* DPD= K doesn't know the function entry point for either loop so no loops are= running.

Whi= ch 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 t= he 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 tha= t's left is to do this trivial work ... and the test program is up and = running: problem solved.

The --lcores doesn't=C2=A0and cannot do this application wo= rk. So what is the practical result of it? What does it do?
--000000000000babc630614e2f1e8--