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 F0C4145A01 for ; Tue, 24 Sep 2024 00:18:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BB7FF4027D; Tue, 24 Sep 2024 00:18:12 +0200 (CEST) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by mails.dpdk.org (Postfix) with ESMTP id 4A6E64027C for ; Tue, 24 Sep 2024 00:18:11 +0200 (CEST) Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-5365a9574b6so6743637e87.1 for ; Mon, 23 Sep 2024 15:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727129890; x=1727734690; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=R9/6XIVSLqMMSfezQWVGJrWfP0/5T344vOHLFtNB2jA=; b=d4QZu9AMlJpW4stZG51BrE7i07YTA0Ng2cyvPgHvcE9w9DYbSPgFw8gk9zJwYIsrn2 Vi0M4e+tQ0DwvwDgq+08nRqY/8LBZ0+TxqWpkN7f+tiqWPDQD5Qa/ZZLQezpT5yH+3u8 Hf+J82mWq9ALWu00mPff7RSseCJeeL7BjLWETNg3sqJaQ+B/hCP3OntXCpQbfqukPbed Oyp3u9wmYUgiF9I5H6in9x98UIXO28xDAEgeWMxwog1HtTH1xR2oUitgY5cEUXd8RP4j /gCvKJa++X3DlORDQQGZN5sDUw6HTJ2p+wN+3DIEK60TXVbgFFWKwjjPd/EcF8quXrz/ CjhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727129890; x=1727734690; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=R9/6XIVSLqMMSfezQWVGJrWfP0/5T344vOHLFtNB2jA=; b=oZmKK3/yysxj90KqDOWwyYfw0o8y20Uea2nHxdJnjiWBZ1q0BWg+MlNL/ec6PwvHSm Q1qaC38xcovX7kghYrAI5SnC2uPqdjmaHkw9HuhAlDAMFS00yeAqIJkWof8RP/DpUf5f EXRxluO1ebaVOS/avtuyoikZvWpx+t0ep5hP8t0v8EFaZl4PE3LkneJoviPQoRxOHGES OlMUAQeLzvDE+YW+VX/RfeuijBMMW0aT5FkXIY7qYvFZ6m4epAD60j+AF8H1V8bH6vTw c/R92HwuwtHnbjYUcEHM9FgicyqPz3+1Q1AHT358ZOD8sOmHDyXYI/WEkcAwBZ5OMEY8 X2UA== X-Forwarded-Encrypted: i=1; AJvYcCX5Lyzjlm+67j5rwPtp5g3+tt/IuEtR2aBJ1Dgcl8HzWWnt016/QxGVQs0PrXeTmrcVBsmpfw==@dpdk.org X-Gm-Message-State: AOJu0YxGXcCf8lJXgPai2yyHN8NFP5lRYzX7HKtOH/z8HOsLwSLJ+2MU e/WdM//VPdIaditeFszfCwpUxxMc+wK6XZE226s4vJNZ+C8g+7rjyrRY6+Rxa2J4yHJ3DIK7zOD ATWJ36th1Xz2bfwHictrwh/8n4Tg= X-Google-Smtp-Source: AGHT+IF2kjgFMvILQZWKS9iZM77DIzff79L+QlPW6X1a7L1pbuub44kfUO26SVNnXES82tgzmIwuAPfqaXsZeZSnbbo= X-Received: by 2002:a05:6512:33ca:b0:52e:936e:a237 with SMTP id 2adb3069b0e04-536ac2e5b7amr7794017e87.16.1727129890386; Mon, 23 Sep 2024 15:18:10 -0700 (PDT) MIME-Version: 1.0 References: <1987164393.11670398.1727125003663.ref@mail.yahoo.com> <1987164393.11670398.1727125003663@mail.yahoo.com> In-Reply-To: From: Nishant Verma Date: Mon, 23 Sep 2024 18:17:58 -0400 Message-ID: Subject: Re: core performance To: Wisam Jaddo Cc: amit sehas , "users@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000009900170622d0c381" 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 --0000000000009900170622d0c381 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also make sure all core you are using are physical core not the logical core. Secondly, check your core isolation options and apply them accordingly. . Regards, Nishant Verma On Mon, Sep 23, 2024 at 6:04=E2=80=AFPM Wisam Jaddo wro= te: > Hello Amit, > > > -----Original Message----- > > From: amit sehas > > Sent: Monday, September 23, 2024 11:57 PM > > To: users@dpdk.org > > Subject: core performance > > > > We are seeing different dpdk threads (launched > via rte_eal_remote_launch()), > > demonstrate very different performance. > > > > > > > > After placing counters all over the code, we realize that some threads > are > > uniformly slow, in other words there is no application level issue that > is > > throttling one thread over the other. We come to the conculsion that > either > > the Cores on which they are running are not at the same frequency which > > seems doubtful or the threads are not getting a chance to execute on th= e > cores > > uniformly. > > > > > > > > It seems that isolcpus has been deprecated in recent versions of linux. > > > > > > > > What is the recommended approach to prevent the kernel from utilizing > some > > CPU threads, for anything other than the threads that are launched on > them. > > If you are wishing to run each thread on separate core, try to use > rte_eal_mp_remote_launch() > instead of rte_eal_remote_launch(), make sure that your CPU is isolated, > and you are passing correct > Cores that were isolated to your app using -c, -l. > > > > > > > > > > Is there some API in dpdk which also helps us determine which CPU core > the > > thread is pinned to? > > > > I did not find any code in dpdk which actually performed pinning of a > thread to > > a CPU core. > > > > > > > > In our case it is more or less certain that the different threads are > simply not > > getting the same CPU core time, as a result some are demonstrating high= er > > throughput than the others ... > > > > > > > > how do we fix this? > > BRs, > Wisam Jaddo > --0000000000009900170622d0c381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also make sure all core you are using are physical core n= ot the logical core.=C2=A0
Secondly, check your core= isolation options and apply them accordingly.


.

Regards,
Nishant Verma


On Mon, Sep 23, 2024 at 6:04=E2=80=AFPM Wisam Jaddo <wisamm@nvidia.com> wrote:
Hello Amit,

> -----Original Message-----
> From: amit sehas <cun23@yahoo.com>
> Sent: Monday, September 23, 2024 11:57 PM
> To: users@dpdk.org=
> Subject: core performance
>
> We are seeing different dpdk threads (launched via=C2=A0rte_eal_remote= _launch()),
> demonstrate very different performance.
>
>
>
> After placing counters all over the code, we realize that some threads= are
> uniformly slow, in other words there is no application level issue tha= t is
> throttling one thread over the other. We come to the conculsion that e= ither
> the Cores on which they are running are not at the same frequency whic= h
> seems doubtful or the threads are not getting a chance to execute on t= he cores
> uniformly.
>
>
>
> It seems that isolcpus has been deprecated in recent versions of linux= .
>
>
>
> What is the recommended approach to prevent the kernel from utilizing = some
> CPU threads, for anything other than the threads that are launched on = them.

If you are wishing to run each thread on separate core, try to use rte_eal_= mp_remote_launch()
instead of rte_eal_remote_launch(), make sure that your CPU is isolated, an= d you are passing correct
Cores that were isolated to your app using -c, -l.


>
>
>
> Is there some API in dpdk which also helps us determine which CPU core= the
> thread is pinned to?
>
> I did not find any code in dpdk which actually performed pinning of a = thread to
> a CPU core.
>
>
>
> In our case it is more or less certain that the different threads are = simply not
> getting the same CPU core time, as a result some are demonstrating hig= her
> throughput than the others ...
>
>
>
> how do we fix this?

BRs,
Wisam Jaddo
--0000000000009900170622d0c381--