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 2DF2846CFE for ; Mon, 11 Aug 2025 17:37:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22EBB402AC; Mon, 11 Aug 2025 17:37:12 +0200 (CEST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by mails.dpdk.org (Postfix) with ESMTP id 1BF6E400D7 for ; Mon, 11 Aug 2025 17:37:11 +0200 (CEST) Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-455fdfb5d04so22743325e9.2 for ; Mon, 11 Aug 2025 08:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1754926631; x=1755531431; 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=+K65mVdsZo5zSkJ4fcTA+y4aX5TDAQNQXptgR4gOVp4=; b=ITr7byhobAP81t7IqLXrYCMaSXP/lbsI2kIPTi64OYrCrxp2y7TaKDC7yw+T7aZwcn Q0EUtq4QQ7+lrRHLYLtzSr6dN6gAvLXd2mRZgLliS9Vo4aXuNNRduj/XDynmIijvIFX4 Sb007p3VANlE5p4m6mAK/Ayb75OTYFiVRT5wni7ucoMWhMOv9AWX+r3yGllpWCr8xGXJ gVeTBo3SqYPI2qb1dqSNMcqlZ81wm8tS7yv3UQfKqm4fomYXPgwR/uSq1I+SFzzu+Ljf 2TcOx5/HT98IhnKJiF9wwntOY0t5yzs35m7zs3jInyN+APudxbiWMxrNEaCZW1VYdNrr 0OWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754926631; x=1755531431; 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=+K65mVdsZo5zSkJ4fcTA+y4aX5TDAQNQXptgR4gOVp4=; b=kZA8XZyvJEZ/HVA8Pn4u5H9FQeXbTd5A/hrf31xBYPHKh/4CSIymCAtiqxFHoJch5X Vm3OOXtyZZmtCa8AQPnlxxEJpg/zvx0ZQByz+wC/O0FvBrBiZ2pGos55rrOgHz5onFK8 IqQFTgwHpAlxTiubGKXP57YNwLf0rovO3J9ZN/V1OiUWuHg3b+mWvofFaaAqyt5BdsL8 n6if4ZEknjDGuta9KUElg+idJ1h9fQigBDm0cZEUbG4MxNwlrfW7UJqFjQTsXQ8ISGfs NG6ly+KMjnhoPBPz3RWWdvQBLc74QLUtfL9r//lJ7y/ocQAo6nFybrF3iPTKAG3dgkvg hsxw== X-Gm-Message-State: AOJu0YxgWPsy4XEyRXkBIwBCImOglvnF2DOu68/diDGTLGiQLKUp/h13 W7+v+Fc4463Jb3VLNYddSR6bDOuuDnBccCi1p+wvXXv27v4aswCpHb4gQ/rwbU7fR88= X-Gm-Gg: ASbGncsX5PCbrkBI97lxTa9Osx8qOJQCdi9t4/mC0XFlfPoe+kZuNfaCM/5ClhwtAto 2eQJ9CN1FdUUjx5lUtnoM2B5bxK12MpKtFnJY98fIkuk/yC0qeuenaBC8Cu96vVCOtRUpuShz9a 7L5tKcy4+uwOgOKBnKtB6EFQFcwkD1BtWPYFERir0qmwtGCalLMaE2/6Yge8vqYvNZqwplnvxU9 UVLint5CvJFWm1v0zSd8WpocN7hAkLn/e094AYoNsQtSCBZ6c61ODpRTe5n0c9f90VoF5cWJR+W 3EnDkaj6+dELTrSG6YmaQuFefc+bBBbxNJI6m86qRYjvtJ4WHXv6Uo3zOEwEfvPAd3VkgNrk3x8 Q50vpVEm6Td/akBzG8ybakftxjlnlZ9kR1hqBfg7sVn+IvuHqHy4tvdsBfWSyebfVcD/R4L6YpP Q= X-Google-Smtp-Source: AGHT+IFzL6ex1riSOplmnQFP2tGK32Cj8jk1qlk7VBT0KXV3N3ebtWrf/zGyz1oRiEIZusl1duVF5A== X-Received: by 2002:a05:600c:524e:b0:458:a559:a693 with SMTP id 5b1f17b1804b1-45a10bf51f7mr1648675e9.18.1754926630645; Mon, 11 Aug 2025 08:37:10 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b79c3b95f4sm40927993f8f.23.2025.08.11.08.37.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Aug 2025 08:37:10 -0700 (PDT) Date: Mon, 11 Aug 2025 08:13:54 -0700 From: Stephen Hemminger To: Daniel May Cc: users@dpdk.org Subject: Re: All non-dpdk application threads assigned to the same core after calling rte_eal_init() Message-ID: <20250811081332.4d25980c@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 Mon, 28 Jul 2025 09:57:28 -0500 Daniel May wrote: > Hello, > > I have a C++ application which uses DPDK to receive packets over two 100 > Gbps interfaces from an FPGA device. > > I've isolated cores 0-2. DPDK is using cores 0-2, main lcore on 0, and two > receive threads on cores 1 and 2. The receive threads read packets from > mbufs and move the packets to a couple of circular buffers. This works as > expected. > > The application starts another set of threads (worker threads) to read from > the circular buffers and handle the data. However, these threads are all > being assigned to core 0, instead of cores 3-n. If you are creating the threads from another thread, the new thread inherits the affinity mask of the parent. In you example, it looks like you are spawning the threads from the main lcore (0). > If I start the worker threads first, before calling rte_eal_init(), they > get assigned to non isolated cores as expected. However, any thread I > start from the main thread after calling rte_eal_init() gets assigned to > the main lcore core (0). I can set affinity manually, but I'd rather the > kernel scheduler do its thing. > > Is there something I need to do to hand control back to the kernel > scheduler for assigning threads to cores after initializing DPDK? The way to fix is to call set affinity to tell kernel what you want.