@Ivan Malov, which version of DPDK are you using? The last year RC? @Erez Shitrit, could you help to confirm if the GCC loop expansion bug of some arm compiler is also present in this branch? I remember there was a GCC bug to always compare with 1 and jump into an infinite loop.
Thanks > -----Original Message----- > From: Ivan Malov <ivan.ma...@arknetworks.am> > Sent: Tuesday, August 12, 2025 12:09 AM > To: 배성종 <sjbae1...@gmail.com> > Cc: users@dpdk.org; Dariusz Sosnowski <dsosnow...@nvidia.com>; Slava > Ovsiienko <viachesl...@nvidia.com>; Bing Zhao <bi...@nvidia.com>; Ori Kam > <or...@nvidia.com>; Suanming Mou <suanmi...@nvidia.com>; Matan Azrad > <ma...@nvidia.com> > Subject: Re: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while > loop (infinite loop) > > External email: Use caution opening links or attachments > > > 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-PRjFVlItUw34zr1t > > nNwkP5AlPTomK87] > > Email > > sjbae1...@gmail.com > > Mobile > > (+82)01089640524 > > Web. > > https://tnet.snu.ac.kr/ > > [a81b6766e3d5b6518dc4010493c7772f5a46f598.png?u=11013800] > > > >
