[v3] app/test-pmd: fix not polling all queues without deferred starting

Message ID 20230529022649.51425-1-haijie1@huawei.com (mailing list archive)
State Superseded, archived
Delegated to: Ferruh Yigit
Headers
Series [v3] app/test-pmd: fix not polling all queues without deferred starting |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/iol-mellanox-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/github-robot: build success github build: passed
ci/iol-broadcom-Functional success Functional Testing PASS
ci/intel-Testing success Testing PASS
ci/iol-x86_64-compile-testing success Testing PASS
ci/iol-aarch64-unit-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-unit-testing success Testing PASS
ci/iol-testing success Testing PASS
ci/iol-x86_64-unit-testing success Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/intel-Functional success Functional PASS
ci/loongarch-unit-testing success Unit Testing PASS
ci/iol-aarch64-compile-testing success Testing PASS

Commit Message

Jie Hai May 29, 2023, 2:26 a.m. UTC
  Each stream has a read-only "disabled" field that control if this
stream should be used to forward. This field depends on states
of Rx/Tx queues, please see
commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").

Currently, the testpmd and DPDK frameworks maintain queue state
separately. That of the primary process of testpmd are set by
deferred_start in the queue configuration. And that of the
framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
is set when the driver enables/disables the queue, and it is
shared between the primary/secondary process.

If the deferred_start is set, the queue is disabled and the
corresponding queue state in the framework changes to stopped.
However, the queue state in the framework does not only come from
this. If the primary/secondary process stops a queue, the related
queue state will change, too. However, the primary process of
testpmd does not know the change brought by this operation.
Therefore, setting the queue state in the primary testpmd by only
the deferred_start is unsafe.

For example, Rx/Tx queues who are stopped before the operations of
stopping and starting port cannot forward packets after these
operations on primary process.

Therefore, the primary process should getting the queue state from
of the framework as the secondary process does, please see commit
e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").

Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
Cc: stable@dpdk.org

Signed-off-by: Jie Hai <haijie1@huawei.com>
---
v1->v2:
1. Fix misspelled word 'deferred'.
2. Fix incorrect format of reference to commits.

v2->v3
1. Fix incorrect format of reference to commits.
---
 app/test-pmd/testpmd.c | 19 +++----------------
 1 file changed, 3 insertions(+), 16 deletions(-)
  

Comments

Ferruh Yigit June 6, 2023, 2:45 p.m. UTC | #1
On 5/29/2023 3:26 AM, Jie Hai wrote:

> 
> Each stream has a read-only "disabled" field that control if this
> stream should be used to forward. This field depends on states
> of Rx/Tx queues, please see
> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
> 
> Currently, the testpmd and DPDK frameworks maintain queue state
> separately. That of the primary process of testpmd are set by
> deferred_start in the queue configuration. And that of the
> framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
> is set when the driver enables/disables the queue, and it is
> shared between the primary/secondary process.
> 
> If the deferred_start is set, the queue is disabled and the
> corresponding queue state in the framework changes to stopped.
> However, the queue state in the framework does not only come from
> this. If the primary/secondary process stops a queue, the related
> queue state will change, too. However, the primary process of
> testpmd does not know the change brought by this operation.
> Therefore, setting the queue state in the primary testpmd by only
> the deferred_start is unsafe.
> 
> For example, Rx/Tx queues who are stopped before the operations of
> stopping and starting port cannot forward packets after these
> operations on primary process.
> 
> Therefore, the primary process should getting the queue state from
> of the framework as the secondary process does, please see commit
> e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").
> 
> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> ---
> v1->v2:
> 1. Fix misspelled word 'deferred'.
> 2. Fix incorrect format of reference to commits.
> 
> v2->v3
> 1. Fix incorrect format of reference to commits.


Hi Jie,

Problem is not clear for me.
Can you please describe more what is not working?
  
Jie Hai June 7, 2023, 7:04 a.m. UTC | #2
On 2023/6/6 22:45, Ferruh Yigit wrote:
> On 5/29/2023 3:26 AM, Jie Hai wrote:
> 
>>
>> Each stream has a read-only "disabled" field that control if this
>> stream should be used to forward. This field depends on states
>> of Rx/Tx queues, please see
>> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
>>
>> Currently, the testpmd and DPDK frameworks maintain queue state
>> separately. That of the primary process of testpmd are set by
>> deferred_start in the queue configuration. And that of the
>> framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
>> is set when the driver enables/disables the queue, and it is
>> shared between the primary/secondary process.
>>
>> If the deferred_start is set, the queue is disabled and the
>> corresponding queue state in the framework changes to stopped.
>> However, the queue state in the framework does not only come from
>> this. If the primary/secondary process stops a queue, the related
>> queue state will change, too. However, the primary process of
>> testpmd does not know the change brought by this operation.
>> Therefore, setting the queue state in the primary testpmd by only
>> the deferred_start is unsafe.
>>
>> For example, Rx/Tx queues who are stopped before the operations of
>> stopping and starting port cannot forward packets after these
>> operations on primary process.
>>
>> Therefore, the primary process should getting the queue state from
>> of the framework as the secondary process does, please see commit
>> e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").
>>
>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> ---
>> v1->v2:
>> 1. Fix misspelled word 'deferred'.
>> 2. Fix incorrect format of reference to commits.
>>
>> v2->v3
>> 1. Fix incorrect format of reference to commits.
> 
> 
> Hi Jie,
> 
> Problem is not clear for me.
> Can you please describe more what is not working?
> 
> .
Hi Ferruh,

Thanks for your question.

Here's an example.
step1: Start the app.
	 dpdk-testpmd -a 0000:35:00.0 --file-prefix=test --proc-type=auto -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 can send or receive
packets.
	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.

Jie Hai,
Thanks
  
Ferruh Yigit June 7, 2023, 5:38 p.m. UTC | #3
On 6/7/2023 8:04 AM, Jie Hai wrote:
> On 2023/6/6 22:45, Ferruh Yigit wrote:
>> On 5/29/2023 3:26 AM, Jie Hai wrote:
>>
>>>
>>> Each stream has a read-only "disabled" field that control if this
>>> stream should be used to forward. This field depends on states
>>> of Rx/Tx queues, please see
>>> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
>>>
>>> Currently, the testpmd and DPDK frameworks maintain queue state
>>> separately. That of the primary process of testpmd are set by
>>> deferred_start in the queue configuration. And that of the
>>> framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
>>> is set when the driver enables/disables the queue, and it is
>>> shared between the primary/secondary process.
>>>
>>> If the deferred_start is set, the queue is disabled and the
>>> corresponding queue state in the framework changes to stopped.
>>> However, the queue state in the framework does not only come from
>>> this. If the primary/secondary process stops a queue, the related
>>> queue state will change, too. However, the primary process of
>>> testpmd does not know the change brought by this operation.
>>> Therefore, setting the queue state in the primary testpmd by only
>>> the deferred_start is unsafe.
>>>
>>> For example, Rx/Tx queues who are stopped before the operations of
>>> stopping and starting port cannot forward packets after these
>>> operations on primary process.
>>>
>>> Therefore, the primary process should getting the queue state from
>>> of the framework as the secondary process does, please see commit
>>> e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").
>>>
>>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>>> ---
>>> v1->v2:
>>> 1. Fix misspelled word 'deferred'.
>>> 2. Fix incorrect format of reference to commits.
>>>
>>> v2->v3
>>> 1. Fix incorrect format of reference to commits.
>>
>>
>> Hi Jie,
>>
>> Problem is not clear for me.
>> Can you please describe more what is not working?
>>
>> .
> Hi Ferruh,
> 
> Thanks for your question.
> 
> Here's an example.
> step1: Start the app.
>      dpdk-testpmd -a 0000:35:00.0 --file-prefix=test --proc-type=auto -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 can send or receive
> packets.
>     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.
> 

Thanks for details, I confirm that problem is valid.
This problem is hard to explain, perhaps it is easier to put above
explanation in the commit log.

Let me check the patch with above explanation.
  
Ferruh Yigit June 7, 2023, 6:12 p.m. UTC | #4
On 5/29/2023 3:26 AM, Jie Hai wrote:

> 
> Each stream has a read-only "disabled" field that control if this
> stream should be used to forward. This field depends on states
> of Rx/Tx queues, please see
> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
> 
> Currently, the testpmd and DPDK frameworks maintain queue state
> separately. That of the primary process of testpmd are set by
> deferred_start in the queue configuration. And that of the
> framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
> is set when the driver enables/disables the queue, and it is
> shared between the primary/secondary process.
> 
> If the deferred_start is set, the queue is disabled and the
> corresponding queue state in the framework changes to stopped.
> However, the queue state in the framework does not only come from
> this. If the primary/secondary process stops a queue, the related
> queue state will change, too. However, the primary process of
> testpmd does not know the change brought by this operation.
> Therefore, setting the queue state in the primary testpmd by only
> the deferred_start is unsafe.
> 
> For example, Rx/Tx queues who are stopped before the operations of
> stopping and starting port cannot forward packets after these
> operations on primary process.
> 
> Therefore, the primary process should getting the queue state from
> of the framework as the secondary process does, please see commit
> e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").
> 
> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> ---
> v1->v2:
> 1. Fix misspelled word 'deferred'.
> 2. Fix incorrect format of reference to commits.
> 
> v2->v3
> 1. Fix incorrect format of reference to commits.
> ---
>  app/test-pmd/testpmd.c | 19 +++----------------
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 5cb6f9252395..a07a67a2639e 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2502,8 +2502,7 @@ start_packet_forwarding(int with_tx_first)
>                 return;
> 
>         if (stream_init != NULL) {
> -               if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> -                       update_queue_state();
> +               update_queue_state();
>                 for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
>                         stream_init(fwd_streams[i]);
>         }
> @@ -2860,9 +2859,6 @@ rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
>                                     socket_id, rx_conf, mp);
>         }
> 
> -       ports[port_id].rxq[rx_queue_id].state = rx_conf->rx_deferred_start ?
> -                                               RTE_ETH_QUEUE_STATE_STOPPED :
> -                                               RTE_ETH_QUEUE_STATE_STARTED;
>         return ret;
>  }
> 
> @@ -3129,9 +3125,6 @@ start_port(portid_t pid)
>                         port->need_reconfig_queues = 0;
>                         /* setup tx queues */
>                         for (qi = 0; qi < nb_txq; qi++) {
> -                               struct rte_eth_txconf *conf =
> -                                                       &port->txq[qi].conf;
> -
>                                 if ((numa_support) &&
>                                         (txring_numa[pi] != NUMA_NO_CONFIG))
>                                         diag = rte_eth_tx_queue_setup(pi, qi,
> @@ -3144,13 +3137,8 @@ start_port(portid_t pid)
>                                                 port->socket_id,
>                                                 &(port->txq[qi].conf));
> 
> -                               if (diag == 0) {
> -                                       port->txq[qi].state =
> -                                               conf->tx_deferred_start ?
> -                                               RTE_ETH_QUEUE_STATE_STOPPED :
> -                                               RTE_ETH_QUEUE_STATE_STARTED;
> +                               if (diag == 0)
>                                         continue;
> -                               }
> 
>                                 /* Fail to setup tx queue, return */
>                                 if (port->port_status == RTE_PORT_HANDLING)
> @@ -3266,8 +3254,7 @@ start_port(portid_t pid)
>                 pl[cfg_pi++] = pi;
>         }
> 
> -       if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> -               update_queue_state();
> +       update_queue_state();
> 

As you described, issue seems caused by commit [1] using testpmd local
queue state information to decide to forward or not on a stream.

There are other commands that update ethdev queue state, this is causing
testpmd and ethdev state information to diverge and causes unexpected
side effects.


For the sample you provided, just above change (that updates queue state
before port start) should be sufficient,
also I guess it is OK to update state in 'start_packet_forwarding()' to
be on safe side.

But not sure about to update deferred_start related changes in this
patch, also details about it makes commit log complex to understand,
what do you think to split deferred_start related changes to another patch?


In commit log, can you please refer to the patch that fixes similar
issue for secondary process [2], that is relevant with this fix,
reference may help to understand this issue better.

@Shiyang, can you please test secondary process fix this patch, to be
sure this is not breaking it again?



[1]
Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")

[2]
5028f207a4fa ("app/testpmd: fix secondary process packet forwarding")
  
Jie Hai June 9, 2023, 8:54 a.m. UTC | #5
On 2023/6/8 2:12, Ferruh Yigit wrote:
> On 5/29/2023 3:26 AM, Jie Hai wrote:
> 
>>
>> Each stream has a read-only "disabled" field that control if this
>> stream should be used to forward. This field depends on states
>> of Rx/Tx queues, please see
>> commit 3c4426db54fc ("app/testpmd: do not poll stopped queues").
>>
>> Currently, the testpmd and DPDK frameworks maintain queue state
>> separately. That of the primary process of testpmd are set by
>> deferred_start in the queue configuration. And that of the
>> framework(dev->data->rx_queue_state or dev->data->tx_queue_state)
>> is set when the driver enables/disables the queue, and it is
>> shared between the primary/secondary process.
>>
>> If the deferred_start is set, the queue is disabled and the
>> corresponding queue state in the framework changes to stopped.
>> However, the queue state in the framework does not only come from
>> this. If the primary/secondary process stops a queue, the related
>> queue state will change, too. However, the primary process of
>> testpmd does not know the change brought by this operation.
>> Therefore, setting the queue state in the primary testpmd by only
>> the deferred_start is unsafe.
>>
>> For example, Rx/Tx queues who are stopped before the operations of
>> stopping and starting port cannot forward packets after these
>> operations on primary process.
>>
>> Therefore, the primary process should getting the queue state from
>> of the framework as the secondary process does, please see commit
>> e065c9aa3e05 ("app/testpmd: fix secondary process packet forwarding").
>>
>> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Jie Hai <haijie1@huawei.com>
>> ---
>> v1->v2:
>> 1. Fix misspelled word 'deferred'.
>> 2. Fix incorrect format of reference to commits.
>>
>> v2->v3
>> 1. Fix incorrect format of reference to commits.
>> ---
>>   app/test-pmd/testpmd.c | 19 +++----------------
>>   1 file changed, 3 insertions(+), 16 deletions(-)
>>
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
>> index 5cb6f9252395..a07a67a2639e 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -2502,8 +2502,7 @@ start_packet_forwarding(int with_tx_first)
>>                  return;
>>
>>          if (stream_init != NULL) {
>> -               if (rte_eal_process_type() == RTE_PROC_SECONDARY)
>> -                       update_queue_state();
>> +               update_queue_state();
>>                  for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
>>                          stream_init(fwd_streams[i]);
>>          }
>> @@ -2860,9 +2859,6 @@ rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
>>                                      socket_id, rx_conf, mp);
>>          }
>>
>> -       ports[port_id].rxq[rx_queue_id].state = rx_conf->rx_deferred_start ?
>> -                                               RTE_ETH_QUEUE_STATE_STOPPED :
>> -                                               RTE_ETH_QUEUE_STATE_STARTED;
>>          return ret;
>>   }
>>
>> @@ -3129,9 +3125,6 @@ start_port(portid_t pid)
>>                          port->need_reconfig_queues = 0;
>>                          /* setup tx queues */
>>                          for (qi = 0; qi < nb_txq; qi++) {
>> -                               struct rte_eth_txconf *conf =
>> -                                                       &port->txq[qi].conf;
>> -
>>                                  if ((numa_support) &&
>>                                          (txring_numa[pi] != NUMA_NO_CONFIG))
>>                                          diag = rte_eth_tx_queue_setup(pi, qi,
>> @@ -3144,13 +3137,8 @@ start_port(portid_t pid)
>>                                                  port->socket_id,
>>                                                  &(port->txq[qi].conf));
>>
>> -                               if (diag == 0) {
>> -                                       port->txq[qi].state =
>> -                                               conf->tx_deferred_start ?
>> -                                               RTE_ETH_QUEUE_STATE_STOPPED :
>> -                                               RTE_ETH_QUEUE_STATE_STARTED;
>> +                               if (diag == 0)
>>                                          continue;
>> -                               }
>>
>>                                  /* Fail to setup tx queue, return */
>>                                  if (port->port_status == RTE_PORT_HANDLING)
>> @@ -3266,8 +3254,7 @@ start_port(portid_t pid)
>>                  pl[cfg_pi++] = pi;
>>          }
>>
>> -       if (rte_eal_process_type() == RTE_PROC_SECONDARY)
>> -               update_queue_state();
>> +       update_queue_state();
>>
> 
> As you described, issue seems caused by commit [1] using testpmd local
> queue state information to decide to forward or not on a stream.
> 
> There are other commands that update ethdev queue state, this is causing
> testpmd and ethdev state information to diverge and causes unexpected
> side effects.
> 
> 
> For the sample you provided, just above change (that updates queue state
> before port start) should be sufficient,
> also I guess it is OK to update state in 'start_packet_forwarding()' to
> be on safe side.
> 
> But not sure about to update deferred_start related changes in this
> patch, also details about it makes commit log complex to understand,
> what do you think to split deferred_start related changes to another patch?
> 
I think I should drop the changes on deferred_start. It may cause PMDs 
supporting 'deferred_start' but not supporting 
'rte_eth_tx_queue_info_get' or 'rte_eth_rx_queue_info_get' takes no 
effect when set 'deferred_start' on.

A better way is to check when updating the queue state. If this is the 
case, keep the testpmd state to the original value so that the original 
behavior is not changed.

> 
> In commit log, can you please refer to the patch that fixes similar
> issue for secondary process [2], that is relevant with this fix,
> reference may help to understand this issue better.
Ok. I will.
> 
> @Shiyang, can you please test secondary process fix this patch, to be
> sure this is not breaking it again?
> 
> 
> 
> [1]
> Fixes: 3c4426db54fc ("app/testpmd: do not poll stopped queues")
> 
> [2]
> 5028f207a4fa ("app/testpmd: fix secondary process packet forwarding")
> 
> .
  

Patch

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 5cb6f9252395..a07a67a2639e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2502,8 +2502,7 @@  start_packet_forwarding(int with_tx_first)
 		return;
 
 	if (stream_init != NULL) {
-		if (rte_eal_process_type() == RTE_PROC_SECONDARY)
-			update_queue_state();
+		update_queue_state();
 		for (i = 0; i < cur_fwd_config.nb_fwd_streams; i++)
 			stream_init(fwd_streams[i]);
 	}
@@ -2860,9 +2859,6 @@  rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
 				    socket_id, rx_conf, mp);
 	}
 
-	ports[port_id].rxq[rx_queue_id].state = rx_conf->rx_deferred_start ?
-						RTE_ETH_QUEUE_STATE_STOPPED :
-						RTE_ETH_QUEUE_STATE_STARTED;
 	return ret;
 }
 
@@ -3129,9 +3125,6 @@  start_port(portid_t pid)
 			port->need_reconfig_queues = 0;
 			/* setup tx queues */
 			for (qi = 0; qi < nb_txq; qi++) {
-				struct rte_eth_txconf *conf =
-							&port->txq[qi].conf;
-
 				if ((numa_support) &&
 					(txring_numa[pi] != NUMA_NO_CONFIG))
 					diag = rte_eth_tx_queue_setup(pi, qi,
@@ -3144,13 +3137,8 @@  start_port(portid_t pid)
 						port->socket_id,
 						&(port->txq[qi].conf));
 
-				if (diag == 0) {
-					port->txq[qi].state =
-						conf->tx_deferred_start ?
-						RTE_ETH_QUEUE_STATE_STOPPED :
-						RTE_ETH_QUEUE_STATE_STARTED;
+				if (diag == 0)
 					continue;
-				}
 
 				/* Fail to setup tx queue, return */
 				if (port->port_status == RTE_PORT_HANDLING)
@@ -3266,8 +3254,7 @@  start_port(portid_t pid)
 		pl[cfg_pi++] = pi;
 	}
 
-	if (rte_eal_process_type() == RTE_PROC_SECONDARY)
-		update_queue_state();
+	update_queue_state();
 
 	if (at_least_one_port_successfully_started && !no_link_check)
 		check_all_ports_link_status(RTE_PORT_ALL);