On 6/20/2023 11:07 AM, Jie Hai wrote:
> 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: sta...@dpdk.org
>>>
>>> Signed-off-by: Jie Hai <haij...@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, I will continue to process the patch.
