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 CA89DA04FD; Mon, 4 Jul 2022 04:37:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2FCEF427F0; Mon, 4 Jul 2022 04:37:37 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 8A8DC40E09; Mon, 4 Jul 2022 04:37:34 +0200 (CEST) Received: from dggemv704-chm.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Lbqf51WwDz1L8nT; Mon, 4 Jul 2022 10:35:09 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by dggemv704-chm.china.huawei.com (10.3.19.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 4 Jul 2022 10:36:59 +0800 Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 4 Jul 2022 10:36:58 +0800 Message-ID: <9a5ab8bb-ccdd-25d2-65d6-370ef95ab712@huawei.com> Date: Mon, 4 Jul 2022 10:36:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] app/testpmd: fix secondary process cannot dump packet To: "Zhang, Peng1X" , Andrew Rybchenko , "dev@dpdk.org" CC: "Singh, Aman Deep" , "Zhang, Yuying" , "stable@dpdk.org" References: <20220623181502.181567-1-peng1x.zhang@intel.com> <5bd19b16-f878-98fe-e1ea-d992c1ffcaa7@oktetlabs.ru> From: "lihuisong (C)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Peng1X, 在 2022/7/1 19:36, Zhang, Peng1X 写道: > Hi, > In fact, the patch is aim to fix this issue that secondary process cannot dump packet after start testpmd. > This issue is induced by commit id is 3c4426db54fc ("app/testpmd: do not poll stopped queues"). After > secondary process start, the default value of Rx/Tx queue state maintained by testpmd is > 'RTE_ETH_QUEUE_STATE_STOPPED', the 'fsm[sm_id]->disabled' flag will set true according to queues > state, then packet cannot forward and dump. I get your meaning. However, failing to dump packet isn't the first exception, and the first one is that testpmd doesn't call 'struct fwd_engine::packet_fwd()' to receive or send packet. So, I think you should describe and resolve this problem from this point. This patch cannot completely resolve this problem. The Tx queue state should also be added here. > > 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. @Andrew, what do you think? Thanks, Huisong > >> -----Original Message----- >> From: lihuisong (C) >> Sent: Wednesday, June 29, 2022 10:55 AM >> To: Andrew Rybchenko ; Zhang, Peng1X >> ; dev@dpdk.org >> Cc: Singh, Aman Deep ; Zhang, Yuying >> ; stable@dpdk.org >> Subject: Re: [PATCH] app/testpmd: fix secondary process cannot dump packet >> >> >> 在 2022/6/23 20:10, Andrew Rybchenko 写道: >>> On 6/23/22 21:15, peng1x.zhang@intel.com wrote: >>>> From: Peng Zhang >>>> >>>> The origin design is whether testpmd is primary or not, if state of >>>> receive queue is stop, then packets will not be dumped for show. >>>> While to secondary process, receive queue will not be set up, and >>>> state will still be stop even if testpmd is started. So packets of >>>> stated secondary process cannot be dumped for show. >>>> >>>> The current design is to secondary process state of queue will be set >>>> to start after testpmd is started. Then packets of started secondary >>>> process can be dumped for show. >>>> >>>> Fixes: a550baf24af9 ("app/testpmd: support multi-process") >>>> Cc: stable@dpdk.org >>>> >>>> Signed-off-by: Peng Zhang >>>> --- >>>>   app/test-pmd/testpmd.c | 12 ++++++++++++ >>>>   1 file changed, 12 insertions(+) >>>> >>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index >>>> 205d98ee3d..93ba7e7c9b 100644 >>>> --- a/app/test-pmd/testpmd.c >>>> +++ b/app/test-pmd/testpmd.c >>>> @@ -3007,6 +3007,18 @@ start_port(portid_t pid) >>>>               if (setup_hairpin_queues(pi, p_pi, cnt_pi) != 0) >>>>                   return -1; >>>>           } >>>> + >>>> +        if (port->need_reconfig_queues > 0 && !is_proc_primary()) { >>>> +            struct rte_eth_rxconf *rx_conf; >>>> +            for (qi = 0; qi < nb_rxq; qi++) { >>>> +                rx_conf = &(port->rxq[qi].conf); >>>> +                ports[pi].rxq[qi].state = >>>> +                    rx_conf->rx_deferred_start ? >>>> +                    RTE_ETH_QUEUE_STATE_STOPPED : >>>> +                    RTE_ETH_QUEUE_STATE_STARTED; >>> I'm not sure why it is correct to assume that deferred queue is not >>> yet started. >> +1. >> >> We should also consider whether the queue state can be changed in secondary. >> The 'rx_conf->rx_deferred_start' is the data in secondary. >> Why not use 'dev->data->rx_queue_state[]'. >> >> In fact, the issue you memtioned was introduced the following patch: >> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues") >> >> The root cause of this issue is that the default value of Rx/Tx queue state >> maintained by testpmd is 'RTE_ETH_QUEUE_STATE_STOPPED'. As a result, >> secondary doesn't start polling thread to receive packets when start packet >> forwarding. And now, secondary cannot receive and send any packets. >> >> Could you fix it together? >>>> +            } >>>> +        } >>>> + >>>>           configure_rxtx_dump_callbacks(verbose_level); >>>>           if (clear_ptypes) { >>>>               diag = rte_eth_dev_set_ptypes(pi, RTE_PTYPE_UNKNOWN, >>> .