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 6628246CFF for ; Mon, 11 Aug 2025 18:08:43 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 393364067E; Mon, 11 Aug 2025 18:08:43 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id 23C2B400D7 for ; Mon, 11 Aug 2025 18:08:42 +0200 (CEST) Received: from debian (unknown [78.109.69.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 242D7E0ACC; Mon, 11 Aug 2025 20:08:41 +0400 (+04) DKIM-Filter: OpenDKIM Filter v2.11.0 agw.arknetworks.am 242D7E0ACC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arknetworks.am; s=default; t=1754928521; bh=O4SxtftZPHi6nJhS9cX2H6LH6QuVMi0ECsgm9nJXLqA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wAaEomzMcOIaZfn+KoTWQknoDPN6CazVmJ+9sdJ5NOUooSxG0o0sXKKA1qHya5rUk 4FT8WJ8XkxoezNXVIjnPHJ5YMzIyhG/J4WD4LwVV+qdVnX9hvcHKjRXP4WHWjRYUwu vK848p1+o38E7HzFxhXUsUE03RyONXW93iKPtks4c8xVeeqJsOLmESKMMoXW8dJSVk ngdng4xWceWGyFIuRDlagPOFeJGjEfKQ4WpsG0pf+Q/Tnrqg2pMjFzhH0bTIwX68PA et/BiuJFHeP9Kl/zM0S3+Ed/nuVexQWO5/KE/eZ/GeVAA7RnVM4+x6wnDdK4QWuIg1 UFxfLbo4De7kQ== Date: Mon, 11 Aug 2025 20:08:38 +0400 (+04) From: Ivan Malov To: =?EUC-KR?B?uei8usG+?= cc: users@dpdk.org, "M: Dariusz Sosnowski" , "M: Viacheslav Ovsiienko" , "M: Bing Zhao" , "M: Ori Kam" , "M: Suanming Mou" , "M: Matan Azrad" Subject: Re: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop) In-Reply-To: Message-ID: <9c57e90b-4216-cc15-6ff3-b8ed8cd322d5@arknetworks.am> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1639447896-1754928521=:9932" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1639447896-1754928521=:9932 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Mon, 28 Jul 2025, 배성종 wrote: > 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’ve observed that when multiple cores simultaneously insert 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—though 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’m 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_flow_push/pull() in multi-core scenarios? > Perhaps my question is a bit out of place and wrong, but, given the fact there are no code snippets to take a look at, are you using separate flow queues for submitting the operations, one flow queue per lcore? Thank you. > Thank you for your time and support. > > Sincerely, > Seongjong Bae M.S. Student T-Networking Lab. > [AIorK4yCWXBmHrQ1GGSZ1Kc18irHfB1S9x_FqTeAHsxNIdnf_olG-PRjFVlItUw34zr1tnNwkP5AlPTomK87] > Email > sjbae1999@gmail.com > Mobile > (+82)01089640524 > Web. > https://tnet.snu.ac.kr/ > [a81b6766e3d5b6518dc4010493c7772f5a46f598.png?u=11013800] > > --8323328-1639447896-1754928521=:9932--