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 395A9467B7; Thu, 22 May 2025 13:04:53 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 038B4402D1; Thu, 22 May 2025 13:04:53 +0200 (CEST) Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by mails.dpdk.org (Postfix) with ESMTP id 1B17140144 for ; Thu, 22 May 2025 04:45:26 +0200 (CEST) Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-875b8e006f8so2110064241.0 for ; Wed, 21 May 2025 19:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747881925; x=1748486725; 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=4miqewFuR94tYynevwTvBygbzHl08rz+CQi8cN/4sm4=; b=FrCnTohCoDGTP5eAk2+QsaXtqST1mSaFQ/A7gtHEEP6nLQb0t5Cg43wd9jhjO0rUS0 3tS8Njx713T9nVvVbAVLdRF1KtaDbodt13bEPKTymPV1WBxgXuCXWnLQrLDLQ+Bi/Qnd j6EqaqT8MS9pty2DHC5QR7tm37RWHdktoRP9UMk8rZjegM26keBvnFWj2UkhS159o4uQ jmGUQvxsXjuxjmz/ywTtMdE8wGdiTZ8Np+0xLVhmF9eQgDjEb+FlJvFli444HF0Fby2e iSrwrD1MiABRa3DS8w6q9izgGeLcbxK70mYt7slAq5Rtc2vPQq4iZY5w2xQWKEygfyQ7 RVFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747881925; x=1748486725; 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=4miqewFuR94tYynevwTvBygbzHl08rz+CQi8cN/4sm4=; b=HeHiBxPZPlQT0wT1fk6F2NopGhSPtDKktkn9lBcOp8waeuUnjww/IK3w6KGCXRdQE8 4cWQVfATxo411c0JGBal+GwOIV6PIqKZNs0a1U5DPw/grg4Mq9wNpRF5DY33xwXaYZQ/ c9T7W2B6z3qoACdtNXL8YMCZNKiUf35OnZFMu/7qA268Amndf5eVqW1TjWglNLsvJWI8 R1ytqBJCpBmJHWFQsaxIU6QrC7Gxuzao47dPD2eKN0wNp205yHummDE79YOvRgtceM8b NcEwYUTARi39wnZoZSc2CrfU47fU4XlNILt2i6RCA9Uyg6urPLu2vuKRLj2eIQTAWY5C bPkQ== X-Gm-Message-State: AOJu0YyNjmUu0TbzDQoD3ANxqm8g9wVbZOBv5K9oPiwXn7AejTclp9Gz YSfwclKO0pR00QVgkrbabTgHWir/BHA0G5IMasR+CAc+xk/aZi7jDdkYcuan5AsDWbmXgT3+Xyy bs8fb0nofQbB/ASMx+W4aRAq7cv7Ngsg= X-Gm-Gg: ASbGncs6KyVvys3S/C7Pn5wZvip92fc6I7zWR7ePLhuuGfwp1Tbm9YEvcdG4osPVwkG GciKjWURzFLbI9sUxjUtUJgYjGPRs+YZIjaVYEigoOJ0lnioSghNEGKKkfoxMcAR6N0cK93P4Vq UkRJNKE6nAkhkMMYKP9gcy+wEUEhfg6R1r X-Google-Smtp-Source: AGHT+IEXrmwe59cqKpQcblgbyZUhkAm5e0A7OIJKiId1siCJANb2AsYz99rJF4pQFJyCcDGH4KBXBZIpx8xcoNPoiGk= X-Received: by 2002:a05:6102:4194:b0:4b6:5e0f:6ddc with SMTP id ada2fe7eead31-4dfa6bc7682mr20242784137.14.1747881925148; Wed, 21 May 2025 19:45:25 -0700 (PDT) MIME-Version: 1.0 References: <20250521071845.50d6f9e1@hermes.local> In-Reply-To: <20250521071845.50d6f9e1@hermes.local> From: farooq basha Date: Thu, 22 May 2025 08:15:14 +0530 X-Gm-Features: AX0GCFvZtW7Pss4DU-HxZVexqkydNTMgFHkpeOeN8FI2CYjnEXZsS2C0O99bOCg Message-ID: Subject: Re: [dpdk-dev] Regarding HQOS with run-to-completion Model To: stephen@networkplumber.org Cc: dev@dpdk.org Content-Type: multipart/alternative; boundary="0000000000004208a50635b079e1" X-Mailman-Approved-At: Thu, 22 May 2025 13:04:52 +0200 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000004208a50635b079e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Stephen for addressing my queries , and it is helpful. One more follow up question on the same , Can DPDK HQOS be customized based on Use case ? For example: Hqos config for one of the use cases , *One Port , One Subport , 16 Pipes & Each Pipe with only one TC*. 16 pipe config was allowed but changing the 13TCs to 1TC is not allowed per Pipe. Can I still use 13 TCs but use the QueueSize as 0, Can that impact performance ? Thanks Farooq.J On Wed, May 21, 2025 at 7:48=E2=80=AFPM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Mon, 28 Apr 2025 16:55:07 +0530 > farooq basha wrote: > > > Hello DevTeam, > > > > I am planning to use DPDK HQOS for Traffic shaping with a > > run-to-completion Model. While I was reading the dpdk-qos document, I > came > > across the following statement. > > > > "*Running enqueue and dequeue operations for the same output port from > > different cores is likely to cause significant impact on scheduler=E2= =80=99s > > performance and it is therefore not recommended"* > > > > Let's take an example, Port1 & Port2 have 4 Rx queues and each Queue > > mapped to a different CPU. Traffic coming on port1 gets forwarded to > port2 > > . With the above limitation application needs to take a lock before doi= ng > > rte_sched_port_enqueue & dequeue operation. Performance is limited to > only > > 1 CPU even though Traffic is coming on 4 Different CPUs. > > > > Correct me if my understanding is Wrong? > > > > Thanks > > Basha > > The HQOS code is not thread safe so yes you need a lock. > The traffic scheduling (QOS) needs to be at last stage of the pipeline ju= st > before mbufs are passed to the device. > > The issue is that QOS is single threaded, so lock is required. > > The statement is misleading, the real overhead is the lock; the secondary > overhead is the cache miss that will happen if processing on different > cores. > But if you are doing that you are going to cut performance a lot from cac= he > misses. > --0000000000004208a50635b079e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Stephen for addressing my queries , and it is helpf= ul.=C2=A0
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 One more follow u= p question on the same ,=C2=A0 =C2=A0Can DPDK HQOS be customized based on U= se case ?
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 For example= : Hqos config for one of the use cases ,=C2=A0 One Port , One Subport , = 16 Pipes & Each Pipe with only one TC.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016= pipe=C2=A0config was allowed but changing the 13TCs to 1TC is not allowed = per Pipe.
=C2=A0
=C2=A0 =C2=A0 Can I still use 13 TCs b= ut use the QueueSize as 0, Can that impact performance ?=C2=A0 =C2=A0
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0=C2=A0
Thanks<= /div>
Farooq.J
=C2=A0
=C2=A0=C2=A0

<= div class=3D"gmail_quote gmail_quote_container">
On Wed, May 21, 2025 at 7:48=E2=80=AFPM Stephen Hemminger <stephen@networkplumber.org&= gt; wrote:
On Mo= n, 28 Apr 2025 16:55:07 +0530
farooq basha <farooq.juturu@gmail.com> wrote:

> Hello DevTeam,
>
>=C2=A0 =C2=A0 =C2=A0I am planning to use DPDK HQOS for Traffic shaping = with a
> run-to-completion Model. While I was reading the dpdk-qos document, I = came
> across the following statement.
>
> "*Running enqueue and dequeue operations for the same output port= from
> different cores is likely to cause significant impact on scheduler=E2= =80=99s
> performance and it is therefore not recommended"*
>
>=C2=A0 Let's take an=C2=A0 example, Port1=C2=A0 & Port2 have 4 = Rx queues and each Queue
> mapped to a different CPU. Traffic coming on port1=C2=A0 gets forwarde= d to port2
> . With the above limitation application needs to take a lock before do= ing
> rte_sched_port_enqueue & dequeue operation. Performance is limited= to only
> 1 CPU even though Traffic is coming on 4 Different CPUs.
>
> Correct me if my understanding is Wrong?
>
> Thanks
> Basha

The HQOS code is not thread safe so yes you need a lock.
The traffic scheduling (QOS) needs to be at last stage of the pipeline just=
before mbufs are passed to the device.

The issue is that QOS is single threaded, so lock is required.

The statement is misleading, the real overhead is the lock; the secondary overhead is the cache miss that will happen if processing on different core= s.
But if you are doing that you are going to cut performance a lot from cache=
misses.
--0000000000004208a50635b079e1--