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 4697246CFD for ; Mon, 11 Aug 2025 15:11:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 38AE540DD5; Mon, 11 Aug 2025 15:11:33 +0200 (CEST) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by mails.dpdk.org (Postfix) with ESMTP id DB5D44026C for ; Mon, 28 Jul 2025 12:50:32 +0200 (CEST) Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-60bf5a08729so8033180a12.0 for ; Mon, 28 Jul 2025 03:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753699832; x=1754304632; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=sZUs7cc0CIzI4zFi/C3m4WjpDaarmLtn0G8eJ98ZJws=; b=Ydlbo8MyI+iiLY2P1ykCybiUDh7z5u31Yts9j7neJsupZnvsmpIx98Y9iA6+LO/Qbs 0oiAUnkfO1+u4dTD07U9UheSKDWsUGQ/x6Yopr9tMhD4HkbxOs2YiiBR816m9fXZlvhN myvV3P0JT0dFnGWTvKpJcSS/5fLS0P1X6YWPnoneueoEJfiCh1ZGp/R/eeQM/fM10EVK 7hlfQ3QafmBPRY+y90rf2RyCy29So4841d45zyjMGRmxtftmq56hFFaxQDiouKus71cV hA5GJRwYZ9zn8qOebT9s9MrBxKCCWGKcJGtwNIm6QXJftLNVDFiKT9dUwXRRakVgkwCj MA6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753699832; x=1754304632; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=sZUs7cc0CIzI4zFi/C3m4WjpDaarmLtn0G8eJ98ZJws=; b=vy2mrXC/Q2/mibsO3yK+EJFh2YgskMU8FCaxld281qZnTbusqW8TV9zKbbjezvRk6b vy19EVzp+CQ+e23swP9mdfUpygmkCML98oPP+KSk59SBZibYToE7RL9bJB2RZUFC9bzu 9v9TVK993x+0jTd8s/DshxTH7tqIsFUCliqV3ANJDKtqqxPBVmiGLzo5zaay6TRC68gN 2oa+Yyqvtdf10yij+MY5wg0wqdo6fe2duem5MLP8ZV5N+5eEjhBilbj+zYQUxngljxnX wEWFV2HTinaQiqUZtvWuPcOtrgw0oZH9ChdqWwK2bvskWp5pLoV8/Tqh+b/HRIkvsueq G9uQ== X-Gm-Message-State: AOJu0YxLyU28i7lC3rOlqOEjDLJ9a/31dIrELRZgqFvqLBmaoutXy/Ib Fp+xyCTlDus7Txg0Qd3gmuoU3kidpoOn24L588SuJKSf51y8uW5cyXUPiHKOt6WGcJS1f28bD23 bO+26XWs7Byq9TRcoMqJDeWRvlYAs0z+1lKObCg== X-Gm-Gg: ASbGncsv6O8RW85/FfCylM4pSwGleAKYHWoWn4tFpC9wy2zTHnCaPOv1s16SvZdDPtT yLQEHaQYl6QIsmfUZ6Hjcdk2AhK47cFvGHDiJT7PbgphelN1xaVzpzpOnNaZu6hPwY8IuUI7cAz TA1DfLnFhQ8fn5iwQG50Ni8O0DuCsRNNIm4ia2ocpyKvslcr5OQVC2pQ9n3ppTuUMquny3T+QMn vVZicU= X-Google-Smtp-Source: AGHT+IFOy/UvbLmGKAyIxiMdsolzQC2dlUtzd9r4VR7vD9aniVusiQou6komTfJxHU4gpYcRy5xcWmacoGZ1tx/Jav8= X-Received: by 2002:a17:907:7b8b:b0:ade:3bec:ea40 with SMTP id a640c23a62f3a-af61c2b346fmr1231080766b.10.1753699831415; Mon, 28 Jul 2025 03:50:31 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?67Cw7ISx7KKF?= Date: Mon, 28 Jul 2025 19:49:55 +0900 X-Gm-Features: Ac12FXx0YjQE4N1ouvbpZfGK1I6N_ncyRIhKHo3Xd49CVg9hIcGfpVq1t1JkeFE Message-ID: Subject: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop) To: users@dpdk.org Cc: "M: Dariusz Sosnowski" , "M: Viacheslav Ovsiienko" , "M: Bing Zhao" , "M: Ori Kam" , "M: Suanming Mou" , "M: Matan Azrad" Content-Type: multipart/alternative; boundary="0000000000007e8b16063afb0f6a" 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 --0000000000007e8b16063afb0f6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello commit authors (and maintainers), I'm currently working with rte_flow_async_create() using the postpone flag, along with rte_flow_push/pull() for batching, in a scenario involving thousands of flows on a BlueField-2 system. My goal is to implement hardware steering such that ingress traffic bypasses the ARM core of the BF2, and egress traffic does the same. According to the DPDK documentation, rte_flow_push/pull() seems to be intended for use as a batch operation, wrapping a large for loop that issues multiple flow operations, and then committing them to hardware in one go. However, I=E2=80=99ve observed that when multiple cores simultaneously inse= rt flow rules, using rte_flow_push/pull() in such a batched way can result in the rule insertion operations not being properly transmitted to the hardware. Specifically, the internal function mlx5dr_send_all_dep_wqe() ends up getting stuck in its while loop. Interestingly, if I call rte_flow_push/pull() after *each* individual rte_flow_async_create() operation, even though that usage seems contrary to the intended batching model, the infinite loop issue is significantly mitigated. The frequency of getting stuck in mlx5dr_send_all_dep_wqe() drops drastically=E2=80=94though it still occurs occasionally. In summary, calling rte_flow_push/pull() after each rte_flow_async_create() seems to avoid the infinite loop, but I=E2=80=99m unsure if this is an expe= cted usage pattern. I would like to ask: - Is this behavior intentional? - Am I misunderstanding the design or usage expectations for rte_flow_push/pull() in multi-core scenarios? Thank you for your time and support. Sincerely, *Seongjong Bae *M.S. Student T-Networking Lab. *Email* sjbae1999@gmail.com *Mobile* (+82)01089640524 *Web.* https://tnet.snu.ac.kr/ --0000000000007e8b16063afb0f6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello commit authors (and maintainers),
I'm currently working with rte_flow_async_create() using the postpone flag, along with rte_flow_push/p= ull() for batching, in a scenario involving thousands of flows on a = BlueField-2 system.

My goal is to implement hardware steering such that ingress traffic bypa= sses the ARM core of the BF2, and egress traffic does the same.

According to the DPDK documentation, rte_flow_push/pull() s= eems to be intended for use as a batch operation, wrapping a large fo= r loop that issues multiple flow operations, and then committing the= m to hardware in one go.

However, I=E2=80=99ve observed that when multiple cores simultaneously i= nsert flow rules, using rte_flow_push/pull() in such a batched= way can result in the rule insertion operations not being properly transmi= tted to the hardware. Specifically, the internal function mlx5dr_send= _all_dep_wqe() ends up getting stuck in its while loop.=

Interestingly, if I call rte_flow_push/pull() after each individual rte_flow_async_create() operation, e= ven though that usage seems contrary to the intended batching model, the in= finite loop issue is significantly mitigated. The frequency of getting stuc= k in mlx5dr_send_all_dep_wqe() drops drastically=E2=80=94thoug= h it still occurs occasionally.

In summary, calling rte_flow_push/pull() after each r= te_flow_async_create() seems to avoid the infinite loop, but I=E2=80= =99m unsure if this is an expected usage pattern. I would like to ask:

  • Is this behavior intentional?

  • Am I misunderstanding the design or usage expectations for rte_flo= w_push/pull() in multi-core scenarios?

Thank you for your time and support.

<= div style=3D"color:rgb(34,34,34)">Sincerely,
=
Seongjong Bae= =C2=A0M.S. Student=C2=A0T-Networking Lab.

Email<= font face=3D"times new roman, serif">sjbae1999@gmail.com
Mobile= (+82)01089640524
Web.https://tnet.snu.ac.kr/
3D"" --0000000000007e8b16063afb0f6a--