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 76BA943D85 for ; Sat, 30 Mar 2024 17:52:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3CE674025E; Sat, 30 Mar 2024 17:52:06 +0100 (CET) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by mails.dpdk.org (Postfix) with ESMTP id 5B2ED4021D for ; Sat, 30 Mar 2024 17:52:05 +0100 (CET) Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-5e4613f2b56so1985456a12.1 for ; Sat, 30 Mar 2024 09:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1711817524; x=1712422324; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fTe5HsU4h+KmH2pTtr996T/SiAUrrlG0pXQANFaZhsE=; b=ermQPoebUUw/i+oD8vm1stc0o9h1C3Uoc4/GBBDWuSFgwWh2xKEognyYW0aeKJ3B/B 4FsKm+Ybe7Z19fyZErbMaLNEkSGQYeKF9XIlLgUdZga3Yefgp176SvNpKTqvZD9fOf33 VYvkrLPXt0rKFR/3yZmjCm32FUqjQM2ca8FTYLXqfhI879xuLAbQAVz6VyzBhH+D1oid x2V24Ti7VzManBsKiy0OcYHTC5ys5tuFp+8RAUJT0bMXRG/kkOQLnhLOhg626bqAzcvn P2CamRbVQqqXlMu1nlFoRUjh0B2lZN8Bq3Rst7fcg7mZx2AdM74nvXk2O7s5Keg2P1dY mFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711817524; x=1712422324; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fTe5HsU4h+KmH2pTtr996T/SiAUrrlG0pXQANFaZhsE=; b=bSFJ/+lp8qRGK26dY6iOP56+VDzUuruLJcUSN6m/Rb/W2AHNlTtriLkwjiaWQbTDHK JUrOWbq/mUXvoZD9Rxhc3QJ/aA5HCZUMJcm6jkO8FSxh4PisZ3SkS3S1qFlyspE5IE+y zcPcp+FWora0Jwh0buytEYnzsJMbSHy8OiRY1bw3Anhn3Sq4gw/bTwbbj1Yxg3NQ1rDe QGavSh3+STYukz5eH0d7Jkl+aMsJCY8XgfsHswNhvuSmqbReSa2K/7UkAtgDzsT7m1Og bEU/KE6yrNXfb5k4aND8YO7HsoxdMMu0PJzlVimH2j56heuY4PquJ7h7aCbPmPoYKekq NMUA== X-Gm-Message-State: AOJu0YwMBzEApvnRWGHWkZw9kM8qS2zmmbkouEhlBPRBtj/WmZ1cdVkt OBdYstVfMwzACHgJVeFsEBvjS75p5qun9YPg22aamsxtzHyRUZqvCgYy9VpiTE0= X-Google-Smtp-Source: AGHT+IGmcj/0xP+CTVu3FeesX1Q05+6Lebr4KtfFPLn/FJxSO3OiWullsvsGv5OpA4bxbvAMhLLqvA== X-Received: by 2002:a05:6a20:3946:b0:1a3:32e5:f38a with SMTP id r6-20020a056a20394600b001a332e5f38amr5520181pzg.45.1711817524492; Sat, 30 Mar 2024 09:52:04 -0700 (PDT) Received: from hermes.local (204-195-123-203.wavecable.com. [204.195.123.203]) by smtp.gmail.com with ESMTPSA id p16-20020a170902e75000b001dd7a97a266sm5446861plf.282.2024.03.30.09.52.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Mar 2024 09:52:04 -0700 (PDT) Date: Sat, 30 Mar 2024 09:52:02 -0700 From: Stephen Hemminger To: fwefew 4t4tg <7532yahoo@gmail.com> Cc: users@dpdk.org Subject: Re: --lcores: what it does and does not do Message-ID: <20240330095202.6cdf59bc@hermes.local> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Sat, 30 Mar 2024 12:06:15 -0400 fwefew 4t4tg <7532yahoo@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() }