DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Shiyang He <shiyangx.he@intel.com>, dev@dpdk.org
Cc: yidingx.zhou@intel.com, stable@dpdk.org,
	Yuying Zhang <yuying.zhang@intel.com>,
	Aman Singh <aman.deep.singh@intel.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	Matan Azrad <matan@nvidia.com>,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Subject: Re: [PATCH v3] app/testpmd: fix secondary process not forwarding
Date: Mon, 6 Mar 2023 15:05:58 +0000	[thread overview]
Message-ID: <6b982bad-f9e6-62be-7a0d-30c7431889ad@amd.com> (raw)
In-Reply-To: <20230223144106.707999-1-shiyangx.he@intel.com>

On 2/23/2023 2:41 PM, Shiyang He wrote:
> Under multi-process scenario, the secondary process gets queue state
> from the wrong location (the global variable 'ports'). Therefore, the
> secondary process can not forward since "stream_init" is not called.
> 
> This commit fixes the issue by calling 'rte_eth_rx/tx_queue_info_get'
> to get queue state from shared memory.
> 
> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Shiyang He <shiyangx.he@intel.com>
> Acked-by: Yuying Zhang <yuying.zhang@intel.com>
> 
> v3: Add return value description
> ---
>  app/test-pmd/testpmd.c | 45 ++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 0c14325b8d..a050472aea 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2418,9 +2418,50 @@ 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++)
> +	if (stream_init != NULL) {
> +		for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++) {
> +			if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> +				struct fwd_stream *fs = fwd_streams[i];
> +				struct rte_eth_rxq_info rx_qinfo;
> +				struct rte_eth_txq_info tx_qinfo;
> +				int32_t rc;
> +				rc = rte_eth_rx_queue_info_get(fs->rx_port,
> +						fs->rx_queue, &rx_qinfo);
> +				if (rc == 0) {
> +					ports[fs->rx_port].rxq[fs->rx_queue].state =
> +						rx_qinfo.queue_state;
> +				} else if (rc == -ENOTSUP) {
> +					/* Set the rxq state to RTE_ETH_QUEUE_STATE_STARTED
> +					 * to ensure that the PMDs do not implement
> +					 * rte_eth_rx_queue_info_get can forward.
> +					 */
> +					ports[fs->rx_port].rxq[fs->rx_queue].state =
> +						RTE_ETH_QUEUE_STATE_STARTED;
> +				} else {
> +					TESTPMD_LOG(WARNING,
> +						"Failed to get rx queue info\n");
> +				}
> +
> +				rc = rte_eth_tx_queue_info_get(fs->tx_port,
> +						fs->tx_queue, &tx_qinfo);
> +				if (rc == 0) {
> +					ports[fs->tx_port].txq[fs->tx_queue].state =
> +						tx_qinfo.queue_state;
> +				} else if (rc == -ENOTSUP) {
> +					/* Set the txq state to RTE_ETH_QUEUE_STATE_STARTED
> +					 * to ensure that the PMDs do not implement
> +					 * rte_eth_tx_queue_info_get can forward.
> +					 */
> +					ports[fs->tx_port].txq[fs->tx_queue].state =
> +						RTE_ETH_QUEUE_STATE_STARTED;
> +				} else {
> +					TESTPMD_LOG(WARNING,
> +						"Failed to get tx queue info\n");
> +				}
> +			}
>  			stream_init(fwd_streams[i]);
> +		}
> +	}
>  


Testpmd duplicates some dpdk/ethdev state/config in application level,
and this can bite in multiple cases, as it is happening here.

I am not sure if this was a design decision, but I think instead of
testpmd storing ethdev related state/config in application level, it
should store only application level state/config, and when ethdev
related state/config is required app should get it directly from ethdev.

It may be too late already for testpmd, there is a mixed usage, but I am
for preferring this approach when there is an opportunity.



For above issue, why queue state needs to be stored in application level
'port' variable?
Where is this queue state used?

Can it work to get queue state directly from ethdev where this state is
used, instead of storing it in the 'port' variable in advance?

And perhaps testpmd 'port' variable can be updated there, both for
primary and secondary, for backward compatibility (other existing users
of this queue state).

What do you think?


  parent reply	other threads:[~2023-03-06 15:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30  7:55 [PATCH] " Shiyang He
2022-12-30 17:23 ` Stephen Hemminger
2023-01-04  2:02   ` He, ShiyangX
2023-01-13  9:07     ` He, ShiyangX
2023-02-08  3:22       ` Zhang, Yuying
2023-02-08  6:38         ` He, ShiyangX
2023-02-20  5:39           ` Zhang, Yuying
2023-02-20 12:45 ` lihuisong (C)
2023-02-21  2:52   ` He, ShiyangX
2023-02-21  6:37     ` lihuisong (C)
2023-02-21  6:51       ` He, ShiyangX
2023-02-21 15:44 ` [PATCH v2] " Shiyang He
2023-02-22  6:20   ` lihuisong (C)
2023-02-23 14:41 ` [PATCH v3] " Shiyang He
2023-02-23  8:08   ` lihuisong (C)
2023-03-06 15:16     ` Ferruh Yigit
2023-03-06 15:05   ` Ferruh Yigit [this message]
2023-03-07  3:25     ` He, ShiyangX
2023-03-07 11:41       ` Ferruh Yigit
2023-03-08  2:05         ` He, ShiyangX
2023-03-08  2:54           ` lihuisong (C)
2023-03-08  9:54             ` Ferruh Yigit
2023-03-08 16:19   ` [PATCH v4] " Shiyang He
2023-03-08 10:20     ` Ferruh Yigit

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=6b982bad-f9e6-62be-7a0d-30c7431889ad@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=aman.deep.singh@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=matan@nvidia.com \
    --cc=shiyangx.he@intel.com \
    --cc=stable@dpdk.org \
    --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).