From: Jie Hai <haijie1@huawei.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
Matan Azrad <matan@nvidia.com>,
Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: <dev@dpdk.org>, <liudongdong3@huawei.com>, <shiyangx.he@intel.com>
Subject: Re: [PATCH v4] app/testpmd: fix primary process not polling all queues
Date: Tue, 20 Jun 2023 18:07:50 +0800 [thread overview]
Message-ID: <9a0a53e2-2566-f13a-96ce-3ec5b839bf81@huawei.com> (raw)
In-Reply-To: <eb497a42-0abc-4a72-8e45-bea61d37b9f8@amd.com>
On 2023/6/9 19:10, Ferruh Yigit wrote:
> On 6/9/2023 10:03 AM, Jie Hai wrote:
>> Here's how the problem arises.
>> step1: Start the app.
>> dpdk-testpmd -a 0000:35:00.0 -l 0-3 -- -i --rxq=10 --txq=10
>>
>> step2: Perform the following steps and send traffic. As expected,
>> queue 7 does not send or receive packets, and other queues do.
>> port 0 rxq 7 stop
>> port 0 txq 7 stop
>> set fwd mac
>> start
>>
>> step3: Perform the following steps and send traffic. All queues
>> are expected to send and receive packets normally, but that's not
>> the case for queue 7.
>> stop
>> port stop all
>> port start all
>> start
>> show port xstats all
>>
>> In fact, only the value of rx_q7_packets for queue 7 is not zero,
>> which means queue 7 is enabled for the driver but is not involved
>> in packet receiving and forwarding by software. If we check queue
>> state by command 'show rxq info 0 7' and 'show txq info 0 7',
>> we see queue 7 is started as other queues are.
>> Rx queue state: started
>> Tx queue state: started
>> The queue 7 is started but cannot forward. That's the problem.
>>
>> We know that each stream has a read-only "disabled" field that
>> control if this stream should be used to forward. This field
>> depends on testpmd local queue state, please see
>> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
>> DPDK framework maintains ethdev queue state that drivers reported,
>> which indicates the real state of queues.
>>
>> There are commands that update these two kind queue state such as
>> 'port X rxq|txq start|stop'. But these operations take effect only
>> in one stop-start round. In the following stop-start round, the
>> preceding operations do not take effect anymore. However, only
>> the ethdev queue state is updated, causing the testpmd and ethdev
>> state information to diverge and causing unexpected side effects
>> as above problem.
>>
>> There was a similar problem for the secondary process, please see
>> commit 5028f207a4fa ("app/testpmd: fix secondary process packet
>> forwarding").
>>
>> This patch applies its workaround with some difference to the
>> primary process. Not all PMDs implement rte_eth_rx_queue_info_get and
>> rte_eth_tx_queue_info_get, however they may support deferred_start
>> with primary process. To not break their behavior, retain the original
>> testpmd local queue state for those PMDs.
>>
>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>>
>
> Patch looks good to me, but since it has potential side effects,
>
> Can some from test team verify following before continue:
> a) Secondary testpmd
> b) Deferred Queue
>
> Thanks,
> Ferruh
>
>
Hi Ferruh,
I tested them with hns3 driver. The results are the same before and
after the patch is applied. The results are as follows:
case1: Secondary testpmd
Action: Secondary testpmd stop a queue and primary testpmd start the queue.
Result: The queue can forward for both process.
case2:
Action: Set a queue with deferred_start on for a primary process.
Result: The queue cannot forward until deferred_start is off.
Thanks,
Jie Hai
>
> .
next prev parent reply other threads:[~2023-06-20 10:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 9:26 [PATCH] app/test-pmd: fix not polling all queues without defered starting Jie Hai
2023-05-08 3:10 ` [PATCH v2] app/test-pmd: fix not polling all queues without deferred starting Jie Hai
2023-05-29 2:26 ` [PATCH v3] " Jie Hai
2023-06-06 14:45 ` Ferruh Yigit
2023-06-07 7:04 ` Jie Hai
2023-06-07 17:38 ` Ferruh Yigit
2023-06-07 18:12 ` Ferruh Yigit
2023-06-09 8:54 ` Jie Hai
2023-06-09 9:03 ` [PATCH v4] app/testpmd: fix primary process not polling all queues Jie Hai
2023-06-09 11:10 ` Ferruh Yigit
2023-06-20 10:07 ` Jie Hai [this message]
2023-06-20 10:57 ` Ferruh Yigit
2023-06-20 17:05 ` Ferruh Yigit
2023-06-22 16:40 ` Ali Alnubani
2023-06-26 9:30 ` Jie Hai
2023-06-27 11:05 ` Ferruh Yigit
2023-07-03 13:40 ` Ali Alnubani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a0a53e2-2566-f13a-96ce-3ec5b839bf81@huawei.com \
--to=haijie1@huawei.com \
--cc=aman.deep.singh@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=ferruh.yigit@amd.com \
--cc=liudongdong3@huawei.com \
--cc=matan@nvidia.com \
--cc=shiyangx.he@intel.com \
--cc=yuying.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).