From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: "lihuisong (C)" <lihuisong@huawei.com>,
"Zhang, Peng1X" <peng1x.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Singh, Aman Deep" <aman.deep.singh@intel.com>,
"Zhang, Yuying" <yuying.zhang@intel.com>,
"Zhou, YidingX" <yidingx.zhou@intel.com>
Subject: Re: [PATCH v3] app/testpmd: fix incorrect queues state of secondary process
Date: Mon, 17 Oct 2022 11:05:06 +0300 [thread overview]
Message-ID: <4e383f34-e990-9af0-46f8-4d328c7d9ccc@oktetlabs.ru> (raw)
In-Reply-To: <04c582f4-08c2-14c3-653d-4eac2e012181@huawei.com>
On 9/13/22 04:26, lihuisong (C) wrote:
>
> 在 2022/9/10 17:21, Zhang, Peng1X 写道:
>>
>>> -----Original Message-----
>>> From: lihuisong (C) <lihuisong@huawei.com>
>>> Sent: Wednesday, September 7, 2022 9:53 AM
>>> To: Zhang, Peng1X <peng1x.zhang@intel.com>; dev@dpdk.org
>>> Cc: andrew.rybchenko@oktetlabs.ru; Singh, Aman Deep
>>> <aman.deep.singh@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>;
>>> stable@dpdk.org
>>> Subject: Re: [PATCH v3] app/testpmd: fix incorrect queues state of
>>> secondary
>>> process
>>>
>>>
>>> 在 2022/9/6 22:53, Peng Zhang 写道:
>>>> Primary process could set up queues state correctly when starting
>>>> port, while secondary process not. Under multi-process scenario,
>>> "stream_init"
>>>> function would get wrong queues state for secondary process.
>>>>
>>>> This commit is to get queues state from ethdev which is located in
>>>> shared memory.
>>>>
>>>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Peng Zhang <peng1x.zhang@intel.com>
>>>>
>>>> ---
>>>> v3:
>>>> - Modify the parameter of rx or tx queue state array
>>>> v2:
>>>> - Change the way of getting secondary process queues states
>>>> ---
>>>> app/test-pmd/testpmd.c | 22 +++++++++++++++++++---
>>>> 1 file changed, 19 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>>> addcbcac85..977ec4fa28 100644
>>>> --- a/app/test-pmd/testpmd.c
>>>> +++ b/app/test-pmd/testpmd.c
>>>> @@ -75,6 +75,8 @@
>>>>
>>>> #include "testpmd.h"
>>>>
>>>> +#include <ethdev_driver.h>
>>> This header file is internal, app shouldn't use it.
+1
>> In this case not all PMDs implement 'rte_eth_rx/tx_queue_info_get()'
>> and ethdev won't return 'dev->data->rx/tx_queue_state'.
> I don't think Rx/Tx queue state needs to be put in the API above.
> The queue state is modified by calling
> 'rte_eth_dev_rx/tx_queue_stop/start'.
> Can we create a new API to report queue state? like,
> 'rte_eth_dev_rx/tx_queue_state_get'.
We can and it does not require driver callback since ethdev
layer knows the queue state, but do we really need it?
Application controls queues state and should know the state
internally.
> If some PMDs do not support 'rte_eth_dev_rx/tx_queue_stop/start', the new
> API always return 'START' state and preserves its original behavior.
It is not required since ethdev layer knows queue state.
>
> What do you think?
>>
>>>> +
>>>> #ifndef MAP_HUGETLB
>>>> /* FreeBSD may not have MAP_HUGETLB (in fact, it probably
>>>> doesn't) */
>>>> #define HUGE_FLAG (0x40000)
>>>> @@ -2402,10 +2404,24 @@ start_packet_forwarding(int with_tx_first)
>>>> if (!pkt_fwd_shared_rxq_check())
>>>> return;
>>>>
>>>> - if (stream_init != NULL)
>>>> - for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
>>>> - stream_init(fwd_streams[i]);
>>>> + if (stream_init != NULL) {
>>>> + for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++) {
>>>> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
>>>> + struct fwd_stream *fs = fwd_streams[i];
>>>> + struct rte_eth_dev_data *dev_rx_data,
>>> *dev_tx_data;
>>>> +
>>>> + dev_rx_data = (&rte_eth_devices[fs->rx_port])-
>>>> data;
>>>> + dev_tx_data = (&rte_eth_devices[fs->tx_port])-
>>>> data;
>>>> +
>>>> + uint8_t rx_state = dev_rx_data-
>>>> rx_queue_state[fs->rx_queue];
>>>> + ports[fs->rx_port].rxq[fs->rx_queue].state =
>>> rx_state;
>>>> + uint8_t tx_state = dev_tx_data-
>>>> tx_queue_state[fs->tx_queue];
>>>> + ports[fs->tx_port].txq[fs->tx_queue].state =
>>> tx_state;
>>>> + }
>>>>
>>>> + stream_init(fwd_streams[i]);
>>>> + }
>>>> + }
>>>>
>>> Suggest that an API in ethdev layer can be encapsulated to obtain the
>>> device
>>> Rx/Tx queue state.
>>> Both primary and secondary process get or set queue state by this API.
>> Suggestion sounds good, maybe better to add a new API in ethdev layer.
>>
>> @andrew, what's your opinion about this solution and huisong's
>> suggestion?
May be it is really more convenient to have ethdev API to get
queue state, but may be it is too late for the API in the
release cycle phase. I'm sorry for late review.
>>
>>>> port_fwd_begin = cur_fwd_config.fwd_eng->port_fwd_begin;
>>>> if (port_fwd_begin != NULL) {
>>>> for (i = 0; i < cur_fwd_config.nb_fwd_ports; i++) {
next prev parent reply other threads:[~2022-10-17 8:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-23 18:15 [PATCH] app/testpmd: fix secondary process cannot dump packet peng1x.zhang
2022-06-23 12:10 ` Andrew Rybchenko
2022-06-29 2:55 ` lihuisong (C)
2022-07-01 11:36 ` Zhang, Peng1X
2022-07-04 2:36 ` lihuisong (C)
2022-07-04 5:28 ` Dmitry Kozlyuk
2022-07-05 10:12 ` Zhang, Peng1X
2022-07-06 2:00 ` lihuisong (C)
2022-07-06 13:40 ` Andrew Rybchenko
2022-06-27 4:53 ` Zhang, Yuying
2022-07-01 9:21 ` Zhang, Yuying
2022-08-19 10:09 ` [PATCH v2] app/testpmd: fix incorrect queues state of secondary process peng1x.zhang
2022-08-24 18:21 ` Singh, Aman Deep
2022-08-26 7:47 ` Zhang, Peng1X
2022-09-06 14:53 ` [PATCH v3] " Peng Zhang
2022-09-07 1:53 ` lihuisong (C)
2022-09-10 9:21 ` Zhang, Peng1X
2022-09-13 1:26 ` lihuisong (C)
2022-10-17 8:05 ` Andrew Rybchenko [this message]
2022-09-29 1:58 ` Zhou, YidingX
2022-10-13 3:01 ` Zhou, YidingX
2022-10-13 3:33 ` Stephen Hemminger
2022-10-14 10:11 ` Zhou, YidingX
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=4e383f34-e990-9af0-46f8-4d328c7d9ccc@oktetlabs.ru \
--to=andrew.rybchenko@oktetlabs.ru \
--cc=aman.deep.singh@intel.com \
--cc=dev@dpdk.org \
--cc=lihuisong@huawei.com \
--cc=peng1x.zhang@intel.com \
--cc=yidingx.zhou@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).