From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 19745A04FD; Mon, 4 Jul 2022 07:28:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ED6BC410E5; Mon, 4 Jul 2022 07:28:33 +0200 (CEST) Received: from mail-oa1-f53.google.com (mail-oa1-f53.google.com [209.85.160.53]) by mails.dpdk.org (Postfix) with ESMTP id 9426D40E09; Mon, 4 Jul 2022 07:28:32 +0200 (CEST) Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-10be1122de0so4944375fac.7; Sun, 03 Jul 2022 22:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kJMaqRue6qvAmIBwDrwe4T8LGtfhZwlBk55RdgY+N4I=; b=Hux/u5sDKZiBnujs9eXzfCjMOINXWcLHqEivPrku9JpjOuzB6HLKyYZ8NyqBcLukn+ uUEGq1zO0ej2Q3URSV+OQ7b9HjQZWptv2d+J/DQbmVQvy24GDIi4e0jU7Bhp7U00RTlL fsk2kg1tB61Zjm7HMg6GyH+6d65H3XxdVB5kay4hjrNCQ9dCE8zivALHMXmo4UhtXsZX u5o2125AH8A25H3jQ4fERITGkbmbH2l0V34lPjGR1cxufq9yhGGG+cHEbKlUfw21Kpmm amOV6EMy5mQVDIm3k2joF9SoOJyNh1KrnZ5+8jo4QKoy+U06fkNusydfz62T0/OI3Lrc dHeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kJMaqRue6qvAmIBwDrwe4T8LGtfhZwlBk55RdgY+N4I=; b=nEUeTy2Ox2Ct2L8vXltIsHOeBXowcNd4T5velyPknLoIoNYFWglbxXwdugPemVQii9 pvM7H+cixrr6+ubttjoaJnz3V1EVUnejpKDIqtL2XILL1UOC5EeUkAoyGiDjgegvtFNH WfMwnN2st+fgVJZNJrcW24PKojcSMBrcant9FDBbr8B8n98B4Xg67ydb61wDcPDI6Hrk xW4cs6IdKTpOv2682NocPeq8jf9ZK8u3yqDOvglSG96mToCEBLL+Zxg2kqkvxdoE5O9d BEXHfKtoIgo+P5u6LjU9m+R7uz0+O7alkGUwB4jX3prgP4RhMFKQRxzyr86SdJ+WhpZ2 i1yg== X-Gm-Message-State: AJIora8Q/AfQhcmYLL0TRsQcqJj1VF4kD5yFqt1M9buvL/6aPsrEajfm oNMGlrJ+xDYIJWNGLaZWgpiqT+kJHcBz+GvcsHI= X-Google-Smtp-Source: AGRyM1viaZ+/YcSXN2J/QLgFFaLo7L4nGA/ZY+tb20/UpM0rfOEKzWpmPwl1JqB3lnR4xVi4qfsgd8SeD4LSQgIgh7g= X-Received: by 2002:a05:6870:430d:b0:102:572e:ffb with SMTP id w13-20020a056870430d00b00102572e0ffbmr15798332oah.232.1656912511939; Sun, 03 Jul 2022 22:28:31 -0700 (PDT) MIME-Version: 1.0 References: <20220623181502.181567-1-peng1x.zhang@intel.com> <5bd19b16-f878-98fe-e1ea-d992c1ffcaa7@oktetlabs.ru> <c9a3085a-fe90-3d0a-7248-a6aae5adabfd@huawei.com> <CO1PR11MB5105A1E654246FB968CE836ECEBD9@CO1PR11MB5105.namprd11.prod.outlook.com> <9a5ab8bb-ccdd-25d2-65d6-370ef95ab712@huawei.com> In-Reply-To: <9a5ab8bb-ccdd-25d2-65d6-370ef95ab712@huawei.com> From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> Date: Mon, 4 Jul 2022 08:28:21 +0300 Message-ID: <CAEYuUWBS_imJUc7z_uTNPJEQQhk5nhRFu9TdZCi7H63tm469+A@mail.gmail.com> Subject: Re: [PATCH] app/testpmd: fix secondary process cannot dump packet To: "lihuisong (C)" <lihuisong@huawei.com> Cc: "Zhang, Peng1X" <peng1x.zhang@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, "dev@dpdk.org" <dev@dpdk.org>, "Singh, Aman Deep" <aman.deep.singh@intel.com>, "Zhang, Yuying" <yuying.zhang@intel.com>, "stable@dpdk.org" <stable@dpdk.org> Content-Type: multipart/alternative; boundary="000000000000b2b9b505e2f4018e" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org --000000000000b2b9b505e2f4018e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 4, 2022 at 5:37 AM lihuisong (C) <lihuisong@huawei.com> wrote: > [...] > =E5=9C=A8 2022/7/1 19:36, Zhang, Peng1X =E5=86=99=E9=81=93: > [...] > > The reason why not use 'dev->data->rx_queue_state' is whether queue > state is start or stop in primary > > process depend on rx_conf->rx_deferred_start after start testpmd. And > after having started testpmd, > > queue state can be controlled by command for example 'port x rxq x > start'. > > Should we align with the same behavior of queues state for primary and > secondary process after start testpmd? > If primary process stops a queue, but secondary doesn't know. > we have to simplify this queue state problem like you momentioned > if we don't have a good idea. > AFAIU, dev->data->rx_queue_state should be aligned with rx_conf->rx_deferred_start. The reason why testpmd manages the queue state itself in the offending patc= h is that not all PMDs implement `rte_eth_rx/tx_queue_info_get()` and ethdev won't return `dev->data->rx_queue_state` in this case. --000000000000b2b9b505e2f4018e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Mon, Jul 4, 2022 at 5:37 AM lihuisong (C) <<a href=3D"mailto:l= ihuisong@huawei.com">lihuisong@huawei.com</a>> wrote:<br></div><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex">[...]<br> =E5=9C=A8 2022/7/1 19:36, Zhang, Peng1X =E5=86=99=E9=81=93:<br>[...]<br> > The reason why not use 'dev->data->rx_queue_state' is wh= ether queue state is start or stop in primary<br> > process depend on rx_conf->rx_deferred_start after start testpmd. A= nd after having started testpmd,<br> > queue state can be controlled by command for example 'port x rxq x= start'.<br> > Should we align with the same behavior of queues state for primary and= secondary process after start testpmd?<br> If primary process stops a queue, but secondary doesn't know.<br> we have to simplify this queue state problem like you momentioned<br> if we don't have a good idea.<br></blockquote><div><br></div><div>AFAIU= , dev->data->rx_queue_state should be aligned with rx_conf->rx_def= erred_start.</div><div></div><div><div>The reason why testpmd manages the q= ueue state itself in the offending patch<br></div><div>is that not all PMDs= implement `rte_eth_rx/tx_queue_info_get()`</div><div>and ethdev won't = return `dev->data->rx_queue_state` in this case.</div></div></div></d= iv> --000000000000b2b9b505e2f4018e--