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 F328546CFD for ; Mon, 11 Aug 2025 15:11:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E8BB340DDD; Mon, 11 Aug 2025 15:11:33 +0200 (CEST) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by mails.dpdk.org (Postfix) with ESMTP id 355794025A for ; Mon, 28 Jul 2025 16:57:40 +0200 (CEST) Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-31f02b6cd37so777402a91.1 for ; Mon, 28 Jul 2025 07:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753714659; x=1754319459; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CkA+N9HuyoSZgAOR8g7kQ7YEIHlBA3IBbjo4ZBarlYI=; b=mD02k9jjP407eVNiQ5zc73a5/7eqb2YczPM/LbLKjUUtkDdL1/Twfiy31HzECKK0CZ ccRmLG+80F6QtWulsM0MmXU+AYmlLdSSzznd9uh4dpswNATEsL2M5zXRHOe/XaoU0wOm xmfc3yyfMDd+8nmZzcwreUS9Xq0F3od1VSHRi4Uz7C8cisIrd9/8yuuDqXzohe6ZWNe7 C8QEPJLweRcUT5ADreT50KjNNowTpBnY1eKf07wmDjnuNDNmPhYMVszC53wU6wKvsJ/L AyC7WGSS56Tez2d+4OZryDCstEgJK99OzON2/hgxmIY0sQzdQiVrGp3Q6EMJWrWmdQS5 sJSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753714659; x=1754319459; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CkA+N9HuyoSZgAOR8g7kQ7YEIHlBA3IBbjo4ZBarlYI=; b=nXaTKJ/RCoTgCdiUBJxqL/3nZnmgcuOT9bDaOgldE9TLdiG/mj+Z6mcOxJveXFbuJS 1jO6byKABDneBRqeU2AoDG+6t3P6/v9thEjeQ1EaPm6eomHnPG9rAM4dAAd5ZIIVL1PO gK7lGsIlZdHVk2OyXANDZdYPWBVl/xwal5+AHNcNa1W7yENFFJvQiV5fXZ5R/qvk8r0m BtkL+jxQWISz2fEEc3gYscxpHz/N+y6KwmcbnRfV+txTwv5jmIckff4Psho/1qs68btO REQesCpZUpWD2ap3z7hLGqsp0lp6PCSyYsr1yvPcTNTnTTO6YZ4bYdCYkZcwql9uzFYw vemA== X-Gm-Message-State: AOJu0Yygb93x7tTZlvlg6i1/y67KZfM/jaa2gUW5oxaYV3L/o4CvFPVq t8q/e8mtaNEcksRNfIW1opeEA50IyJLCyWR0NfMiGLCYhrNj608RfCmqMZpFsedTFUrCP4+YHNs G5l7tGOduiHw6pzp1EAOGB22VOrRT39YhKYnn X-Gm-Gg: ASbGncuvWQFMaa2b7cGAfR1FJsPfB3L9RF98tqv8e02hMcba8bn6nNpHCaCCwByecjr Kv8oylV1s3D+VHvTzqBP6h2DYQPxsVM6N4CXcAIDLJrIFzf9qK9SUf1ciSmjrwIXJ7R3Jhph2lV B5nTm30QkZODbKLlNuDlQqwUV6Utogo51qkE4X+TAXxyE6YqawJwpPsYHb1EH7IbGdKSJdbUdyE U1fTSM= X-Google-Smtp-Source: AGHT+IHRGWT2634zIDHk9rPQyxu+Z9k48NYkPiuY9XAG2ZlyJjCSNIlPP4W9UWXURYZqnnGVRlFv6a9V148XIArZveE= X-Received: by 2002:a17:90b:2cce:b0:31f:22f:a221 with SMTP id 98e67ed59e1d1-31f022fa385mr3900296a91.29.1753714659012; Mon, 28 Jul 2025 07:57:39 -0700 (PDT) MIME-Version: 1.0 From: Daniel May Date: Mon, 28 Jul 2025 09:57:28 -0500 X-Gm-Features: Ac12FXyZiIK9K6Fjp4cUNNPb-4OHodloL_wHY1odtuHl0u0zuLRogCRApgyVV7E Message-ID: Subject: All non-dpdk application threads assigned to the same core after calling rte_eal_init() To: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000049b3e4063afe83f4" X-Mailman-Approved-At: Mon, 11 Aug 2025 15:11:32 +0200 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 --00000000000049b3e4063afe83f4 Content-Type: text/plain; charset="UTF-8" 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 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? Thanks, Daniel --00000000000049b3e4063afe83f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have a C++ application which u= ses DPDK to receive packets over two 100 Gbps interfaces from an FPGA devic= e.=C2=A0

I've isolated cores 0-2. DPDK is usin= g cores 0-2, main lcore on 0, and two receive threads on cores 1 and 2.=C2= =A0 The receive threads read packets from mbufs and move the packets to a c= ouple of circular buffers.=C2=A0 This works as expected.

The application starts another set of threads (worker threads) to re= ad from the circular buffers and handle the data. However, these threads ar= e all being assigned to core 0, instead of cores 3-n.=C2=A0

<= /div>
If I start the worker threads first, before calling=C2=A0rte_eal_= init(), they get assigned to non isolated cores as expected.=C2=A0 However,= any thread I start from the main thread after calling rte_eal_init() gets = assigned to the main lcore core (0).=C2=A0 I can set affinity manually, but= I'd rather the kernel scheduler do its thing.=C2=A0

Is there something I need to do to hand control back to the kernel s= cheduler for=C2=A0assigning threads to cores after initializing DPDK?
=

Thanks,
Daniel
--00000000000049b3e4063afe83f4--