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 E489146D57 for ; Mon, 18 Aug 2025 09:13:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 953EB4026A; Mon, 18 Aug 2025 09:13:33 +0200 (CEST) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by mails.dpdk.org (Postfix) with ESMTP id B0CC4400EF for ; Wed, 13 Aug 2025 05:46:18 +0200 (CEST) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-af9611d8ff7so88350866b.1 for ; Tue, 12 Aug 2025 20:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755056778; x=1755661578; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=laOfYW1xAaPb3CUPJlIqOrLAXsnQ5iOT4pxQKmONuxM=; b=TOWXhWsvva5p+FOV+Sdax7I2rb1PkR8I+z9k6KeGcI8qNpKVUYDOvMyzWJb3gUIsSf V/7tW6yPTDyV+4W7dag6hsv989/9IuyyB/x11/n6uytiQtATrmhwc6Oy6WqX5V3v8rkR +T+FrfWkjlhRZQaiwZI1batqY3zcDHBX6z6ps1ROVIsnuh6vZCjlgoRRKW1fm+jy2Sqq KvXvhxCvpSkkMUNf/Afxq+B/LMvb3j+YG1tIfo9eO6OyeGwvWVA3RlN3bKNuSV1ZZyFP +dFMNnZTB8cGcvHF9rRigFf0kbOWyctK7nmNoRIZtLC3N1iKv/sOsQdujvE6PBYwgvQN 98Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755056778; x=1755661578; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=laOfYW1xAaPb3CUPJlIqOrLAXsnQ5iOT4pxQKmONuxM=; b=CJ6XwNvJwvFeQKcagwCPkC8PZEpgJ92AFCeDo00K8c08sKYz5lUcIAKa0J8XltPivo sHwKadOie4TxmSdZm/pcmANQ0Ntq8QAxbhws6HFIsTSuvp96ciHkpwniOvyeajMrKbj2 Yj/OhqGyXFQfAfxr0LJWyG7deTyXVYy8Z4MsD+QOg4jr9H/4ypVCSRJSPY+l/hBIJOW+ nukqn80BGOm4FD557GDHLNe9v2jj1eAOYtERJfClOEGURMjw5IOsHVuhhpB/6lCrJmwx xIylN7Gbf03i5ysT+iCnY9fkJ/tprjBlMW/Z1sst0yco2GVVhxDCkTJOP9BQOUiwoCv0 3z1A== X-Forwarded-Encrypted: i=1; AJvYcCUsqYjvH3uqNMxbKi40qq4d/gZJyGrTNRg633FGL2hyYzhCIclj87gPizO6Go7rxeKh/7eu5g==@dpdk.org X-Gm-Message-State: AOJu0Yx+tkBuMSBs0iSp+J51n7mKuRpVm7Q4GPz7FnTKIPxG0gcXA35P scm28u1GCZASsFl9TVXAb3QYzhslI+0V0Q3XibTogcYZC6cabeR8YRVdJgtpxM06p2ICuJKLdeM 5hjLAuTvi5JXyXm+PGkX/oboxP4o8vLSQ5SMFBw== X-Gm-Gg: ASbGncvCQc3Vfyu6VG2MqbAfsj2IzqwrhN0QfKkAYtkHm8XJOffrWQezdgbh7OE1Hrw EoCZcAbREcowYkcCD2UvzLkNtW9OYskLT/NDWswNFIQHL0AYYqrSQB4wsu2dOxdSqZk3eAvL4Ps vTyfTh4AByLTi2k6jd25vVMnPz5vwdYt71/gWL54ZIDpw4bVZBAUHHVlUw9KQLkrQ/ehch2mxj3 tBSvIk= X-Google-Smtp-Source: AGHT+IF5rsFYpyo7fhvLgCwpwlXiSakXfFypBkXdWTj6AyWvQWocalOBFtG5E4R+f1L14f2tQMoqJJ6P+rqsXwCK2NY= X-Received: by 2002:a17:906:f583:b0:ae3:c72f:6383 with SMTP id a640c23a62f3a-afca848ae60mr94177066b.17.1755056777927; Tue, 12 Aug 2025 20:46:17 -0700 (PDT) MIME-Version: 1.0 References: <9c57e90b-4216-cc15-6ff3-b8ed8cd322d5@arknetworks.am> In-Reply-To: From: =?UTF-8?B?67Cw7ISx7KKF?= Date: Wed, 13 Aug 2025 12:45:42 +0900 X-Gm-Features: Ac12FXya6n8bGTtaQoPQfARM46uhGxBsUjbzh5_bsSNMhNqGKUzpPTwsQThbq1k Message-ID: Subject: Re: [DPDK 24.11.3-rc1] rte_flow_async_create() stucks in while loop (infinite loop) To: Bing Zhao Cc: Ivan Malov , Erez Shitrit , "users@dpdk.org" , Dariusz Sosnowski , Slava Ovsiienko , Ori Kam , Suanming Mou , Matan Azrad Content-Type: multipart/alternative; boundary="000000000000cf1fb9063c36ff0f" X-Mailman-Approved-At: Mon, 18 Aug 2025 09:13: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 --000000000000cf1fb9063c36ff0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, @Ivan Malov, I use one flow queue per lcore. Sincerely, *Seongjong Bae *M.S. Student T-Networking Lab. *Email.* sjbae1999@gmail.com *Mobile.* (+82)01089640524 *Web.* https://tnet.snu.ac.kr/ 2025=EB=85=84 8=EC=9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 5:30, B= ing Zhao =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > @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 > > Sent: Tuesday, August 12, 2025 12:09 AM > > To: =EB=B0=B0=EC=84=B1=EC=A2=85 > > Cc: users@dpdk.org; Dariusz Sosnowski ; Slava > > Ovsiienko ; Bing Zhao ; Ori > Kam > > ; Suanming Mou ; Matan Azrad > > > > 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, =EB=B0=B0=EC=84=B1=EC=A2=85 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 i= n > > one go. > > > > > > However, I=E2=80=99ve observed that when multiple cores simultaneousl= y insert > > > flow rules, using rte_flow_push/pull() in such a batched way can resu= lt > > 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 significantl= y > > 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 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 fac= t > > there are no code snippets to take a look at, are you using separate fl= ow > > 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-PRjFVlItUw34zr1= t > > > nNwkP5AlPTomK87] > > > Email > > > sjbae1999@gmail.com > > > Mobile > > > (+82)01089640524 > > > Web. > > > https://tnet.snu.ac.kr/ > > > [a81b6766e3d5b6518dc4010493c7772f5a46f598.png?u=3D11013800] > > > > > > > --000000000000cf1fb9063c36ff0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

@Iva= n Malov, I use one flow queue per lcore.

Sincerely,
Seongjong Bae=C2=A0M.S. Student=C2=A0T-Networking Lab.

<= /tr>
Email.sjbae1999@gmail.com
=
Mobile.(+82)01089640524
Web.= https://tnet.snu.ac.kr/
=


3D""
202= 5=EB=85=84 8=EC=9B=94 12=EC=9D=BC (=ED=99=94) =EC=98=A4=ED=9B=84 5:30, Bing= Zhao <bingz@nvidia.com>=EB= =8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
@Ivan Malov, which version of DPDK are you using? The l= ast year RC?

@Erez Shitrit, could you help to confirm if the GCC loop expansion bug of s= ome arm compiler is also present in this branch?
I remember there was a GCC bug to always compare with 1 and jump into an in= finite loop.

Thanks

> -----Original Message-----
> From: Ivan Malov <ivan.malov@arknetworks.am>
> Sent: Tuesday, August 12, 2025 12:09 AM
> To: =EB=B0=B0=EC=84=B1=EC=A2=85 <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 whil= e
> loop (infinite loop)
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> On Mon, 28 Jul 2025, =EB=B0=B0=EC=84=B1=EC=A2=85 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 traff= ic
> bypasses the ARM core of the BF2, and egress traffic does the same. > >
> > According to the DPDK documentation, rte_flow_push/pull() seems t= o 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 simultane= ously 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 individu= al
> > rte_flow_async_create() operation, even though that usage seems c= ontrary
> to the intended batching model, the infinite loop issue is significant= ly
> 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 expected usage pattern. I would like to ask:
> >
> >=C2=A0 *
> >
> >=C2=A0 =C2=A0 =C2=A0Is this behavior intentional?
> >
> >=C2=A0 *
> >
> >=C2=A0 =C2=A0 =C2=A0Am I misunderstanding the design or usage expe= ctations for
> rte_flow_push/pull() in multi-core scenarios?
> >
>
> Perhaps my question is a bit out of place and wrong, but, given the fa= ct
> there are no code snippets to take a look at, are you using separate f= low
> 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-PRjFVlItUw3= 4zr1t
> > nNwkP5AlPTomK87]
> > Email
> > sjbae199= 9@gmail.com
> > Mobile
> > (+82)01089640524
> > Web.
> > https://tnet.snu.ac.kr/
> > [a81b6766e3d5b6518dc4010493c7772f5a46f598.png?u=3D11013800]
> >
> >
--000000000000cf1fb9063c36ff0f--