[DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop)

[DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop)

[배성종]

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

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?

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/

[-- Attachment #2: Type: text/html, Size: 4863 bytes --]

Re: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop)

[Ivan Malov]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

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]
> 
>

RE: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop)

[Bing Zhao]

@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.malov@arknetworks.am>
> Sent: Tuesday, August 12, 2025 12:09 AM
> To: 배성종 <sjbae1999@gmail.com>
> Cc: users@dpdk.org; Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava
> Ovsiienko <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> <matan@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
> > sjbae1999@gmail.com
> > Mobile
> > (+82)01089640524
> > Web.
> > https://tnet.snu.ac.kr/
> > [a81b6766e3d5b6518dc4010493c7772f5a46f598.png?u=11013800]
> >
> >