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 1432A46751 for ; Thu, 15 May 2025 08:39:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9FD2D402C2; Thu, 15 May 2025 08:38:59 +0200 (CEST) Received: from authsmtp.register.it (authsmtp35.register.it [81.88.55.98]) by mails.dpdk.org (Postfix) with ESMTP id CC78E4025A for ; Wed, 7 May 2025 12:24:12 +0200 (CEST) Received: from DESKTOPPE5KR91 ([95.231.224.119]) by cmsmtp with ESMTPSA id CbwhudF6YR8sRCbwhuVcY6; Wed, 07 May 2025 12:24:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outsys.org; s=key_65m6du3g3t; t=1746613452; bh=B8gkrVaZbNx2w5J4PQOWadyoB6xh7F6+IspkJvwQayU=; h=From:To:Subject:Date; b=UJntq0WcDz2xceA8yvrxJAWdIMh5jofHkA13rC5oqkn+8Ge6IcKQYItBD9hMDHcBE D3rR4o7Hdn/M8kwUQRFDbfpUZOLGyCkHLmqCrxqNhUpn/WKkXDWFp6LX5+s2dn6BEo jWY/DDBzn7yA5WQoHTR4fc285cburjoApL8430lzaA+YdUMlVpXfIhpjDlbDM/YU5O E+bEwccZmz5RkmPJiMkayIziN5gjv21/bzcBiXGt7ik9cVPLD0H4Qf2xzvys/svwW3 Qy+773qYX9S4YPymDz1i3UPQYTpTN5bYF4+WU1WKND+r2ZXDtY9f4uMZx5cPg3fp0d U77q99+WbOl7g== X-Rid: smtp@outsys.eu@95.231.224.119 From: "Ernesto Ruffini" To: Subject: Blocked rte_sched queue Date: Wed, 7 May 2025 12:24:12 +0200 Message-ID: <081c01dbbf3a$2d56c030$88044090$@outsys.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_081D_01DBBF4A.F0E00560" X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adu/OdwgzxUtnHe4QdWNvmEdR4WJkg== Content-Language: en-us X-CMAE-Envelope: MS4xfIT+ShONsS957e5eYo++EtlXNKYaeCCToSO3DqP6WBvmtdDoFrnjaitrSMAgMtuT8Ri8EDlnthcLMB2xrmYJz8w7ALx8SiRUyG1ryp+8cgr6moBq7JgT hYSvOFASP7/KaEePMrutbtmm+8bvPHflARrmckgyNRWjGKXyuWcHaeR4jrJDyMS14WZ/N9gV1SeRdQ== X-Mailman-Approved-At: Thu, 15 May 2025 08:38:58 +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 This is a multipart message in MIME format. ------=_NextPart_000_081D_01DBBF4A.F0E00560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We use DPDK 24.11.1 rte_sched library for shaping traffic, and it happens that some queues, mainly low-bandwidth TCs, from time to time stop sending traffic. After investigating, we found that this happens when a large packet is enqueued: if this is accepted and enqueued in the sched port, it might be too big to be sent out, completely blocking the queue, as there is no mechanism to get rid of that packet, even if it will never be dequeued. In particular, in function grinder_credits_check_with_tc_ov(), pipe_tc_credits are lower than pkt_len, making enough_credit always false, so the packet is never dequeued. This can be seen also using the qos_sched example, setting pipe tc rates to 6250 (50Kbps) on a 100Gbps nic: pipe_tc_credits will be 250, and any packet larger that that will completely block the queue, and no other packets, even small, will ever pass. We could not find any solution other than preventing long packets to be enqueued. Is there any other way to prevent queues from blocking? Thanks ------=_NextPart_000_081D_01DBBF4A.F0E00560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We use DPDK 24.11.1 = rte_sched library for shaping traffic, and it happens that some queues, = mainly low-bandwidth TCs, from time to time stop sending = traffic.

After investigating, we found that this = happens when a large packet is enqueued: if this is accepted and = enqueued in the sched port, it might be too big to be sent out, = completely blocking the queue, as there is no mechanism to get rid of = that packet, even if it will never be dequeued.

 

In particular, in = function grinder_credits_check_with_tc_ov(), pipe_tc_credits are lower = than pkt_len, making enough_credit always false, so the packet is never = dequeued.

 

This can be seen also = using the qos_sched example, setting pipe tc rates to 6250 (50Kbps) on a = 100Gbps nic: pipe_tc_credits will be 250, and any packet larger that = that will completely block the queue, and no other packets, even small, = will ever pass.

 

We could not find any = solution other than preventing long packets to be = enqueued.

Is there any other way to prevent queues from = blocking?

 

Thanks

 

------=_NextPart_000_081D_01DBBF4A.F0E00560--