[dpdk-dev] [PATCH 0/3] Fixes for testpmd

[dpdk-dev] [PATCH 0/3] Fixes for testpmd

[Lijun Ou]

This series add two test bug fixes and a print style.

Hongbo Zheng (1):
  app/testpmd: use of Rx/Tx in testpmd

Huisong Li (2):
  app/testpmd: fix forwarding configuration when DCB test
  app/testpmd: remove forwarding config from parsing Rx and Tx

 app/test-pmd/cmdline.c     | 106 ++++++++++++++++----------------
 app/test-pmd/config.c      | 147 +++++++++++++++++++++++++--------------------
 app/test-pmd/csumonly.c    |  22 +++----
 app/test-pmd/icmpecho.c    |   2 +-
 app/test-pmd/ieee1588fwd.c |  18 +++---
 app/test-pmd/parameters.c  |  50 +++++++--------
 app/test-pmd/testpmd.c     | 132 ++++++++++++++++++++--------------------
 app/test-pmd/testpmd.h     |  28 ++++-----
 app/test-pmd/txonly.c      |   2 +-
 9 files changed, 263 insertions(+), 244 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Lijun Ou]

From: Huisong Li <lihuisong@huawei.com>

Currently, 'nb_fwd_lcores' value are both adjusted based on
'nb_fwd_streams' in rss/simple/icmp_echo_fwd_config_setup. But the
operation is lack for dcb_fwd_config_setup, which may lead to a
bad events where multiple polling threads operate on the same
queue. As a result, various possible exceptions will occur. The
procedure is as follows:

startup testpmd app as follows:
testpmd> port stop all
testpmd> set nbcore 8
testpmd> port config 0 dcb vt off 4 pfc on
testpmd> port config all rxq 16
testpmd> port config all txq 16
testpmd> port start all
testpmd> set fwd mac
Logical Core 1 (socket 0) forwards packets on 4 streams:
RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00
Logical Core 2 (socket 0) forwards packets on 4 streams:
RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
Logical Core 3 (socket 0) forwards packets on 4 streams:
RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00
Logical Core 4 (socket 0) forwards packets on 4 streams:
RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00
RX P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00
Logical Core 5 (socket 0) forwards packets on 1 streams:
RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00
Logical Core 6 (socket 0) forwards packets on 1 streams:
RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00
Logical Core 7 (socket 0) forwards packets on 1 streams:
RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00
Logical Core 8 (socket 0) forwards packets on 1 streams:
RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00

Notice: number of rxq and txq in running cmdline are greater than
used nb_tc.

For the DCB forwarding test, each core is assigned on each traffic class
and each core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
value can be adjusted based on 'total_tc_num' in all forwarding ports.

In addition, after operation of port stop/port start, forwarding
configuration is changed by rss_fwd_config_setup. In "start_port"
function, dcb_test is set to 1 based on dcb_config. So it also
should be cleared when dcb_config is 0.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c  | 19 +++++++++++++++++++
 app/test-pmd/testpmd.c | 12 +++++++-----
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 576d5ac..c89f8cd 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
 	}
 }
 
+static uint16_t
+get_fwd_port_total_tc_num(void)
+{
+	struct rte_eth_dcb_info dcb_info;
+	uint16_t total_tc_num = 0;
+	unsigned int i;
+
+	for (i = 0; i < nb_fwd_ports; i++) {
+		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
+		total_tc_num += dcb_info.nb_tcs;
+	}
+
+	return total_tc_num;
+}
+
 /**
  * For the DCB forwarding test, each core is assigned on each traffic class.
  *
@@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
 	lcoreid_t  lc_id;
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
+	uint16_t total_tc_num = 0;
 	uint8_t tc = 0;
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
 	cur_fwd_config.nb_fwd_streams =
 		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
+	total_tc_num = get_fwd_port_total_tc_num();
+	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
+		cur_fwd_config.nb_fwd_lcores = total_tc_num;
 
 	/* reinitialize forwarding streams */
 	init_fwd_streams();
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 1a57324..7eb810b 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
 	portid_t peer_pl[RTE_MAX_ETHPORTS];
 	int peer_pi;
 
-	if (dcb_test) {
-		dcb_test = 0;
-		dcb_config = 0;
-	}
-
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return;
 
+	/*
+	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
+	 * So it should be cleared when dcb_config is 0.
+	 */
+	if (dcb_config == 0)
+		dcb_test = 0;
+
 	printf("Stopping ports...\n");
 
 	RTE_ETH_FOREACH_DEV(pi) {
-- 
2.7.4

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Li, Xiaoyun]

Hi

> -----Original Message-----
> From: Lijun Ou <oulijun@huawei.com>
> Sent: Friday, March 5, 2021 18:22
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> linuxarm@openeuler.org
> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test
> 
> From: Huisong Li <lihuisong@huawei.com>
> 
The commit message is too long and redundant. Please simplify it.

> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
> dcb_fwd_config_setup, which may lead to a bad events where multiple polling
> threads operate on the same queue. As a result, various possible exceptions will
> occur. The procedure is as follows:
> 
> startup testpmd app as follows:
> testpmd> port stop all
> testpmd> set nbcore 8
> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
> testpmd> config all txq 16 port start all set fwd mac
> Logical Core 1 (socket 0) forwards packets on 4 streams:
> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 2 (socket 0) forwards packets on 4 streams:
> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 3 (socket 0) forwards packets on 4 streams:
> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 4 (socket 0) forwards packets on 4 streams:
> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 5 (socket 0) forwards packets on 1 streams:
> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 6 (socket 0) forwards packets on 1 streams:
> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 7 (socket 0) forwards packets on 1 streams:
> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 Logical
> Core 8 (socket 0) forwards packets on 1 streams:
> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
> 
> Notice: number of rxq and txq in running cmdline are greater than used nb_tc.
> 
> For the DCB forwarding test, each core is assigned on each traffic class and each
> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
> value can be adjusted based on 'total_tc_num' in all forwarding ports.
> 
> In addition, after operation of port stop/port start, forwarding configuration is
> changed by rss_fwd_config_setup. In "start_port"
> function, dcb_test is set to 1 based on dcb_config. So it also should be cleared
> when dcb_config is 0.
> 
> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/config.c  | 19 +++++++++++++++++++  app/test-pmd/testpmd.c |
> 12 +++++++-----
>  2 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> 576d5ac..c89f8cd 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>  	}
>  }
> 
> +static uint16_t
> +get_fwd_port_total_tc_num(void)
> +{
> +	struct rte_eth_dcb_info dcb_info;
> +	uint16_t total_tc_num = 0;
> +	unsigned int i;
> +
> +	for (i = 0; i < nb_fwd_ports; i++) {
> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
> +		total_tc_num += dcb_info.nb_tcs;
> +	}
> +
> +	return total_tc_num;
> +}

It's only 3 lines. Is it really necessary to make it into a function which is not called by anyone else? A comment and the loop are enough.

> +
>  /**
>   * For the DCB forwarding test, each core is assigned on each traffic class.
>   *
> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>  	lcoreid_t  lc_id;
>  	uint16_t nb_rx_queue, nb_tx_queue;
>  	uint16_t i, j, k, sm_id = 0;
> +	uint16_t total_tc_num = 0;
>  	uint8_t tc = 0;
> 
>  	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>  	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>  	cur_fwd_config.nb_fwd_streams =
>  		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
> +	total_tc_num = get_fwd_port_total_tc_num();
> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
> 
>  	/* reinitialize forwarding streams */
>  	init_fwd_streams();
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 1a57324..7eb810b 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>  	portid_t peer_pl[RTE_MAX_ETHPORTS];
>  	int peer_pi;
> 
> -	if (dcb_test) {
> -		dcb_test = 0;
> -		dcb_config = 0;
> -	}
> -
>  	if (port_id_is_invalid(pid, ENABLED_WARN))
>  		return;
> 
> +	/*
> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
> +	 * So it should be cleared when dcb_config is 0.
> +	 */
> +	if (dcb_config == 0)
> +		dcb_test = 0;
> +

I don't understand why are you changing this.
dcb_test will only be set when dcb_config is 1 when starting ports. And both dcb_test and dcb_config will be cleared when stopping ports.
So dcb will only affect when you set port dcb and then start port and when stop port dcb will be cleared.

So what's the problem of original codes?

Your change will cause issues that there's no place to set dcb_config as 0. If you config dcb, then it'll be always dcb mode unless restart the whole testpmd.

>  	printf("Stopping ports...\n");
> 
>  	RTE_ETH_FOREACH_DEV(pi) {
> --
> 2.7.4

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/3/23 16:55, Li, Xiaoyun 写道:
> Hi
> 
>> -----Original Message-----
>> From: Lijun Ou <oulijun@huawei.com>
>> Sent: Friday, March 5, 2021 18:22
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>> linuxarm@openeuler.org
>> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test
>>
>> From: Huisong Li <lihuisong@huawei.com>
>>
> The commit message is too long and redundant. Please simplify it.
> 
OK, I will fix it.
>> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
>> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
>> dcb_fwd_config_setup, which may lead to a bad events where multiple polling
>> threads operate on the same queue. As a result, various possible exceptions will
>> occur. The procedure is as follows:
>>
>> startup testpmd app as follows:
>> testpmd> port stop all
>> testpmd> set nbcore 8
>> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
>> testpmd> config all txq 16 port start all set fwd mac
>> Logical Core 1 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 2 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 3 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 4 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 5 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 6 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 7 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 8 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
>>
>> Notice: number of rxq and txq in running cmdline are greater than used nb_tc.
>>
>> For the DCB forwarding test, each core is assigned on each traffic class and each
>> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
>> value can be adjusted based on 'total_tc_num' in all forwarding ports.
>>
>> In addition, after operation of port stop/port start, forwarding configuration is
>> changed by rss_fwd_config_setup. In "start_port"
>> function, dcb_test is set to 1 based on dcb_config. So it also should be cleared
>> when dcb_config is 0.
>>
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/config.c  | 19 +++++++++++++++++++  app/test-pmd/testpmd.c |
>> 12 +++++++-----
>>   2 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>> 576d5ac..c89f8cd 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>>   	}
>>   }
>>
>> +static uint16_t
>> +get_fwd_port_total_tc_num(void)
>> +{
>> +	struct rte_eth_dcb_info dcb_info;
>> +	uint16_t total_tc_num = 0;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nb_fwd_ports; i++) {
>> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>> +		total_tc_num += dcb_info.nb_tcs;
>> +	}
>> +
>> +	return total_tc_num;
>> +}
> 
> It's only 3 lines. Is it really necessary to make it into a function which is not called by anyone else? A comment and the loop are enough.
> 
>> +
>>   /**
>>    * For the DCB forwarding test, each core is assigned on each traffic class.
>>    *
>> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>>   	lcoreid_t  lc_id;
>>   	uint16_t nb_rx_queue, nb_tx_queue;
>>   	uint16_t i, j, k, sm_id = 0;
>> +	uint16_t total_tc_num = 0;
>>   	uint8_t tc = 0;
>>
>>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>   	cur_fwd_config.nb_fwd_streams =
>>   		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>> +	total_tc_num = get_fwd_port_total_tc_num();
>> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>
>>   	/* reinitialize forwarding streams */
>>   	init_fwd_streams();
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>> 1a57324..7eb810b 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>   	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>   	int peer_pi;
>>
>> -	if (dcb_test) {
>> -		dcb_test = 0;
>> -		dcb_config = 0;
>> -	}
>> -
>>   	if (port_id_is_invalid(pid, ENABLED_WARN))
>>   		return;
>>
>> +	/*
>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>> +	 * So it should be cleared when dcb_config is 0.
>> +	 */
>> +	if (dcb_config == 0)
>> +		dcb_test = 0;
>> +
> 
> I don't understand why are you changing this.
> dcb_test will only be set when dcb_config is 1 when starting ports. And both dcb_test and dcb_config will be cleared when stopping ports.
> So dcb will only affect when you set port dcb and then start port and when stop port dcb will be cleared.
> 
> So what's the problem of original codes?
> 
> Your change will cause issues that there's no place to set dcb_config as 0. If you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
> 
>>   	printf("Stopping ports...\n");
>>
>>   	RTE_ETH_FOREACH_DEV(pi) {
>> --
>> 2.7.4
> 
> .
> 

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/3/23 16:55, Li, Xiaoyun 写道:
> Hi
> 
>> -----Original Message-----
>> From: Lijun Ou <oulijun@huawei.com>
>> Sent: Friday, March 5, 2021 18:22
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>> linuxarm@openeuler.org
>> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test
>>
>> From: Huisong Li <lihuisong@huawei.com>
>>
> The commit message is too long and redundant. Please simplify it.
> 
>> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
>> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
>> dcb_fwd_config_setup, which may lead to a bad events where multiple polling
>> threads operate on the same queue. As a result, various possible exceptions will
>> occur. The procedure is as follows:
>>
>> startup testpmd app as follows:
>> testpmd> port stop all
>> testpmd> set nbcore 8
>> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
>> testpmd> config all txq 16 port start all set fwd mac
>> Logical Core 1 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 2 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 3 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 4 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 5 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 6 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 7 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 8 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
>>
>> Notice: number of rxq and txq in running cmdline are greater than used nb_tc.
>>
>> For the DCB forwarding test, each core is assigned on each traffic class and each
>> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
>> value can be adjusted based on 'total_tc_num' in all forwarding ports.
>>
>> In addition, after operation of port stop/port start, forwarding configuration is
>> changed by rss_fwd_config_setup. In "start_port"
>> function, dcb_test is set to 1 based on dcb_config. So it also should be cleared
>> when dcb_config is 0.
>>
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/config.c  | 19 +++++++++++++++++++  app/test-pmd/testpmd.c |
>> 12 +++++++-----
>>   2 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>> 576d5ac..c89f8cd 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>>   	}
>>   }
>>
>> +static uint16_t
>> +get_fwd_port_total_tc_num(void)
>> +{
>> +	struct rte_eth_dcb_info dcb_info;
>> +	uint16_t total_tc_num = 0;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nb_fwd_ports; i++) {
>> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>> +		total_tc_num += dcb_info.nb_tcs;
>> +	}
>> +
>> +	return total_tc_num;
>> +}
> 
> It's only 3 lines. Is it really necessary to make it into a function which is not called by anyone else? A comment and the loop are enough.
> 
To calculate the total number of TCs on all forwarding ports, we have to 
call  rte_eth_dev_get_dcb_info().  However,  rte_eth_dev_get_dcb_info()
has been called twice by dcb_fwd_config_setup() to setup dcb forwarding 
configuration. The dcb_fwd_config_setup() might be more readable
if encapsulated, I think.  In addition, variables in "cur_fwd_config" 
are initialized more centrally. What do you think?
>> +
>>   /**
>>    * For the DCB forwarding test, each core is assigned on each traffic class.
>>    *
>> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>>   	lcoreid_t  lc_id;
>>   	uint16_t nb_rx_queue, nb_tx_queue;
>>   	uint16_t i, j, k, sm_id = 0;
>> +	uint16_t total_tc_num = 0;
>>   	uint8_t tc = 0;
>>
>>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>   	cur_fwd_config.nb_fwd_streams =
>>   		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>> +	total_tc_num = get_fwd_port_total_tc_num();
>> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>
>>   	/* reinitialize forwarding streams */
>>   	init_fwd_streams();
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>> 1a57324..7eb810b 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>   	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>   	int peer_pi;
>>
>> -	if (dcb_test) {
>> -		dcb_test = 0;
>> -		dcb_config = 0;
>> -	}
>> -
>>   	if (port_id_is_invalid(pid, ENABLED_WARN))
>>   		return;
>>
>> +	/*
>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>> +	 * So it should be cleared when dcb_config is 0.
>> +	 */
>> +	if (dcb_config == 0)
>> +		dcb_test = 0;
>> +
> 
> I don't understand why are you changing this.
> dcb_test will only be set when dcb_config is 1 when starting ports. And both dcb_test and dcb_config will be cleared when stopping ports.
> So dcb will only affect when you set port dcb and then start port and when stop port dcb will be cleared.
> 
> So what's the problem of original codes?
> 
> Your change will cause issues that there's no place to set dcb_config as 0. If you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
> 
>>   	printf("Stopping ports...\n");
>>
>>   	RTE_ETH_FOREACH_DEV(pi) {
>> --
>> 2.7.4
> 
> .
> 

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Tuesday, March 23, 2021 22:18
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB
> test
> 
> 
> 
> 在 2021/3/23 16:55, Li, Xiaoyun 写道:
> > Hi
> >
> >> -----Original Message-----
> >> From: Lijun Ou <oulijun@huawei.com>
> >> Sent: Friday, March 5, 2021 18:22
> >> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >> linuxarm@openeuler.org
> >> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when
> >> DCB test
> >>
> >> From: Huisong Li <lihuisong@huawei.com>
> >>
> > The commit message is too long and redundant. Please simplify it.
> >
<snip>
> >> +static uint16_t
> >> +get_fwd_port_total_tc_num(void)
> >> +{
> >> +	struct rte_eth_dcb_info dcb_info;
> >> +	uint16_t total_tc_num = 0;
> >> +	unsigned int i;
> >> +
> >> +	for (i = 0; i < nb_fwd_ports; i++) {
> >> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
> >> +		total_tc_num += dcb_info.nb_tcs;
> >> +	}
> >> +
> >> +	return total_tc_num;
> >> +}
> >
> > It's only 3 lines. Is it really necessary to make it into a function which is not
> called by anyone else? A comment and the loop are enough.
> >
> To calculate the total number of TCs on all forwarding ports, we have to call
> rte_eth_dev_get_dcb_info().  However,  rte_eth_dev_get_dcb_info() has been
> called twice by dcb_fwd_config_setup() to setup dcb forwarding configuration.
> The dcb_fwd_config_setup() might be more readable if encapsulated, I think.  In
> addition, variables in "cur_fwd_config"
> are initialized more centrally. What do you think?

I'm not familiar with dcb. Why does the rxp_dcb_info get from fwd_ports_ids[0] and txp_dcb_info get from fwd_ports_ids[1]?
Is this a have-to-be? Can it be both from port 0 or last port?
If it can be port 0 or last port, you can just store the last dcb_info after your loop (loop from 0, i++ or loop from last i--).

> >> +
<snip>
> >> --
> >> 2.7.4
> >
> > .
> >

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Ferruh Yigit]

On 3/23/2021 2:17 PM, oulijun wrote:
> 
> 
> 在 2021/3/23 16:55, Li, Xiaoyun 写道:
>> Hi
>>
>>> -----Original Message-----
>>> From: Lijun Ou <oulijun@huawei.com>
>>> Sent: Friday, March 5, 2021 18:22
>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>> linuxarm@openeuler.org
>>> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test
>>>
>>> From: Huisong Li <lihuisong@huawei.com>
>>>
>> The commit message is too long and redundant. Please simplify it.
>>
>>> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
>>> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
>>> dcb_fwd_config_setup, which may lead to a bad events where multiple polling
>>> threads operate on the same queue. As a result, various possible exceptions will
>>> occur. The procedure is as follows:
>>>
>>> startup testpmd app as follows:
>>> testpmd> port stop all
>>> testpmd> set nbcore 8
>>> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
>>> testpmd> config all txq 16 port start all set fwd mac
>>> Logical Core 1 (socket 0) forwards packets on 4 streams:
>>> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 2 (socket 0) forwards packets on 4 streams:
>>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 3 (socket 0) forwards packets on 4 streams:
>>> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 4 (socket 0) forwards packets on 4 streams:
>>> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
>>> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 5 (socket 0) forwards packets on 1 streams:
>>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 6 (socket 0) forwards packets on 1 streams:
>>> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 7 (socket 0) forwards packets on 1 streams:
>>> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 Logical
>>> Core 8 (socket 0) forwards packets on 1 streams:
>>> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
>>>
>>> Notice: number of rxq and txq in running cmdline are greater than used nb_tc.
>>>
>>> For the DCB forwarding test, each core is assigned on each traffic class and 
>>> each
>>> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
>>> value can be adjusted based on 'total_tc_num' in all forwarding ports.
>>>
>>> In addition, after operation of port stop/port start, forwarding 
>>> configuration is
>>> changed by rss_fwd_config_setup. In "start_port"
>>> function, dcb_test is set to 1 based on dcb_config. So it also should be cleared
>>> when dcb_config is 0.
>>>
>>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>> ---
>>>   app/test-pmd/config.c  | 19 +++++++++++++++++++  app/test-pmd/testpmd.c |
>>> 12 +++++++-----
>>>   2 files changed, 26 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>>> 576d5ac..c89f8cd 100644
>>> --- a/app/test-pmd/config.c
>>> +++ b/app/test-pmd/config.c
>>> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>>>       }
>>>   }
>>>
>>> +static uint16_t
>>> +get_fwd_port_total_tc_num(void)
>>> +{
>>> +    struct rte_eth_dcb_info dcb_info;
>>> +    uint16_t total_tc_num = 0;
>>> +    unsigned int i;
>>> +
>>> +    for (i = 0; i < nb_fwd_ports; i++) {
>>> +        (void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>>> +        total_tc_num += dcb_info.nb_tcs;
>>> +    }
>>> +
>>> +    return total_tc_num;
>>> +}
>>
>> It's only 3 lines. Is it really necessary to make it into a function which is 
>> not called by anyone else? A comment and the loop are enough.
>>
> To calculate the total number of TCs on all forwarding ports, we have to call  
> rte_eth_dev_get_dcb_info().  However,  rte_eth_dev_get_dcb_info()
> has been called twice by dcb_fwd_config_setup() to setup dcb forwarding 
> configuration. The dcb_fwd_config_setup() might be more readable
> if encapsulated, I think.  In addition, variables in "cur_fwd_config" are 
> initialized more centrally. What do you think?

+1 to have the function, agree it makes more readable.

But for the PMDs that doesn't support '.get_dcb_info' it will return 0, causing 
'nb_fwd_lcores' to be zero, I think this should be prevented.
Either can add a zero check here, or do the check during "port config # dcb ..." 
and prevent setting 'dcb_config' at first place for those pmds. I think second 
option is better, what do you think.

Overall DCB support in the testpmd seems missing some corner cases and requires 
more update/fix.

>>> +
>>>   /**
>>>    * For the DCB forwarding test, each core is assigned on each traffic class.
>>>    *
>>> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>>>       lcoreid_t  lc_id;
>>>       uint16_t nb_rx_queue, nb_tx_queue;
>>>       uint16_t i, j, k, sm_id = 0;
>>> +    uint16_t total_tc_num = 0;
>>>       uint8_t tc = 0;
>>>
>>>       cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>>       cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>>       cur_fwd_config.nb_fwd_streams =
>>>           (streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>>> +    total_tc_num = get_fwd_port_total_tc_num();
>>> +    if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>>> +        cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>>
>>>       /* reinitialize forwarding streams */
>>>       init_fwd_streams();
>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>> 1a57324..7eb810b 100644
>>> --- a/app/test-pmd/testpmd.c
>>> +++ b/app/test-pmd/testpmd.c
>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>       portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>       int peer_pi;
>>>
>>> -    if (dcb_test) {
>>> -        dcb_test = 0;
>>> -        dcb_config = 0;
>>> -    }
>>> -
>>>       if (port_id_is_invalid(pid, ENABLED_WARN))
>>>           return;
>>>
>>> +    /*
>>> +     * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>>> +     * So it should be cleared when dcb_config is 0.
>>> +     */
>>> +    if (dcb_config == 0)
>>> +        dcb_test = 0;
>>> +
>>
>> I don't understand why are you changing this.
>> dcb_test will only be set when dcb_config is 1 when starting ports. And both 
>> dcb_test and dcb_config will be cleared when stopping ports.
>> So dcb will only affect when you set port dcb and then start port and when 
>> stop port dcb will be cleared.
>>
>> So what's the problem of original codes?
>>
>> Your change will cause issues that there's no place to set dcb_config as 0. If 
>> you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
>>
>>>       printf("Stopping ports...\n");
>>>
>>>       RTE_ETH_FOREACH_DEV(pi) {
>>> -- 
>>> 2.7.4
>>
>> .
>>

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/4/10 9:12, Ferruh Yigit 写道:
> On 3/23/2021 2:17 PM, oulijun wrote:
>>
>>
>> 在 2021/3/23 16:55, Li, Xiaoyun 写道:
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Lijun Ou <oulijun@huawei.com>
>>>> Sent: Friday, March 5, 2021 18:22
>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>> linuxarm@openeuler.org
>>>> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when 
>>>> DCB test
>>>>
>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>
>>> The commit message is too long and redundant. Please simplify it.
>>>
>>>> Currently, 'nb_fwd_lcores' value are both adjusted based on 
>>>> 'nb_fwd_streams' in
>>>> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
>>>> dcb_fwd_config_setup, which may lead to a bad events where multiple 
>>>> polling
>>>> threads operate on the same queue. As a result, various possible 
>>>> exceptions will
>>>> occur. The procedure is as follows:
>>>>
>>>> startup testpmd app as follows:
>>>> testpmd> port stop all
>>>> testpmd> set nbcore 8
>>>> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
>>>> testpmd> config all txq 16 port start all set fwd mac
>>>> Logical Core 1 (socket 0) forwards packets on 4 streams:
>>>> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) 
>>>> peer=02:00:00:00:00:00 RX
>>>> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 
>>>> Logical
>>>> Core 2 (socket 0) forwards packets on 4 streams:
>>>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) 
>>>> peer=02:00:00:00:00:00 RX
>>>> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 
>>>> Logical
>>>> Core 3 (socket 0) forwards packets on 4 streams:
>>>> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) 
>>>> peer=02:00:00:00:00:00 RX
>>>> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 
>>>> Logical
>>>> Core 4 (socket 0) forwards packets on 4 streams:
>>>> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) 
>>>> peer=02:00:00:00:00:00 RX
>>>> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
>>>> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 
>>>> Logical
>>>> Core 5 (socket 0) forwards packets on 1 streams:
>>>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) 
>>>> peer=02:00:00:00:00:00 Logical
>>>> Core 6 (socket 0) forwards packets on 1 streams:
>>>> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) 
>>>> peer=02:00:00:00:00:00 Logical
>>>> Core 7 (socket 0) forwards packets on 1 streams:
>>>> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) 
>>>> peer=02:00:00:00:00:00 Logical
>>>> Core 8 (socket 0) forwards packets on 1 streams:
>>>> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
>>>>
>>>> Notice: number of rxq and txq in running cmdline are greater than 
>>>> used nb_tc.
>>>>
>>>> For the DCB forwarding test, each core is assigned on each traffic 
>>>> class and each
>>>> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
>>>> value can be adjusted based on 'total_tc_num' in all forwarding ports.
>>>>
>>>> In addition, after operation of port stop/port start, forwarding 
>>>> configuration is
>>>> changed by rss_fwd_config_setup. In "start_port"
>>>> function, dcb_test is set to 1 based on dcb_config. So it also 
>>>> should be cleared
>>>> when dcb_config is 0.
>>>>
>>>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> ---
>>>>   app/test-pmd/config.c  | 19 +++++++++++++++++++  
>>>> app/test-pmd/testpmd.c |
>>>> 12 +++++++-----
>>>>   2 files changed, 26 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>>>> 576d5ac..c89f8cd 100644
>>>> --- a/app/test-pmd/config.c
>>>> +++ b/app/test-pmd/config.c
>>>> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>>>>       }
>>>>   }
>>>>
>>>> +static uint16_t
>>>> +get_fwd_port_total_tc_num(void)
>>>> +{
>>>> +    struct rte_eth_dcb_info dcb_info;
>>>> +    uint16_t total_tc_num = 0;
>>>> +    unsigned int i;
>>>> +
>>>> +    for (i = 0; i < nb_fwd_ports; i++) {
>>>> +        (void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>>>> +        total_tc_num += dcb_info.nb_tcs;
>>>> +    }
>>>> +
>>>> +    return total_tc_num;
>>>> +}
>>>
>>> It's only 3 lines. Is it really necessary to make it into a function 
>>> which is not called by anyone else? A comment and the loop are enough.
>>>
>> To calculate the total number of TCs on all forwarding ports, we have 
>> to call rte_eth_dev_get_dcb_info().  However,  rte_eth_dev_get_dcb_info()
>> has been called twice by dcb_fwd_config_setup() to setup dcb 
>> forwarding configuration. The dcb_fwd_config_setup() might be more 
>> readable
>> if encapsulated, I think.  In addition, variables in "cur_fwd_config" 
>> are initialized more centrally. What do you think?
> 
> +1 to have the function, agree it makes more readable.
> 
> But for the PMDs that doesn't support '.get_dcb_info' it will return 0, 
> causing 'nb_fwd_lcores' to be zero, I think this should be prevented.
> Either can add a zero check here, or do the check during "port config # 
> dcb ..." and prevent setting 'dcb_config' at first place for those pmds. 
> I think second option is better, what do you think.
> 
Yes, the second one is the source.
> Overall DCB support in the testpmd seems missing some corner cases and 
> requires more update/fix.
> 
In testpmd, it seems that the code has not been updated for a long time. 
I don't know how other dcb-enabled drivers are tested and how they 
should be used.
Do they not apply this method to test the DCB?
>>>> +
>>>>   /**
>>>>    * For the DCB forwarding test, each core is assigned on each 
>>>> traffic class.
>>>>    *
>>>> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>>>>       lcoreid_t  lc_id;
>>>>       uint16_t nb_rx_queue, nb_tx_queue;
>>>>       uint16_t i, j, k, sm_id = 0;
>>>> +    uint16_t total_tc_num = 0;
>>>>       uint8_t tc = 0;
>>>>
>>>>       cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>>>       cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>>>       cur_fwd_config.nb_fwd_streams =
>>>>           (streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>>>> +    total_tc_num = get_fwd_port_total_tc_num();
>>>> +    if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>>>> +        cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>>>
>>>>       /* reinitialize forwarding streams */
>>>>       init_fwd_streams();
>>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>>> 1a57324..7eb810b 100644
>>>> --- a/app/test-pmd/testpmd.c
>>>> +++ b/app/test-pmd/testpmd.c
>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>       portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>       int peer_pi;
>>>>
>>>> -    if (dcb_test) {
>>>> -        dcb_test = 0;
>>>> -        dcb_config = 0;
>>>> -    }
>>>> -
>>>>       if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>           return;
>>>>
>>>> +    /*
>>>> +     * In "start_port" function, dcb_test is set to 1 based on 
>>>> dcb_config.
>>>> +     * So it should be cleared when dcb_config is 0.
>>>> +     */
>>>> +    if (dcb_config == 0)
>>>> +        dcb_test = 0;
>>>> +
>>>
>>> I don't understand why are you changing this.
>>> dcb_test will only be set when dcb_config is 1 when starting ports. 
>>> And both dcb_test and dcb_config will be cleared when stopping ports.
>>> So dcb will only affect when you set port dcb and then start port and 
>>> when stop port dcb will be cleared.
>>>
>>> So what's the problem of original codes?
>>>
>>> Your change will cause issues that there's no place to set dcb_config 
>>> as 0. If you config dcb, then it'll be always dcb mode unless restart 
>>> the whole testpmd.
>>>
>>>>       printf("Stopping ports...\n");
>>>>
>>>>       RTE_ETH_FOREACH_DEV(pi) {
>>>> -- 
>>>> 2.7.4
>>>
>>> .
>>>
> 
> .
> 

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/3/23 16:55, Li, Xiaoyun 写道:
> Hi
> 
>> -----Original Message-----
>> From: Lijun Ou <oulijun@huawei.com>
>> Sent: Friday, March 5, 2021 18:22
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>> linuxarm@openeuler.org
>> Subject: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test
>>
>> From: Huisong Li <lihuisong@huawei.com>
>>
> The commit message is too long and redundant. Please simplify it.
> 
>> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
>> rss/simple/icmp_echo_fwd_config_setup. But the operation is lack for
>> dcb_fwd_config_setup, which may lead to a bad events where multiple polling
>> threads operate on the same queue. As a result, various possible exceptions will
>> occur. The procedure is as follows:
>>
>> startup testpmd app as follows:
>> testpmd> port stop all
>> testpmd> set nbcore 8
>> testpmd> port config 0 dcb vt off 4 pfc on port config all rxq 16 port
>> testpmd> config all txq 16 port start all set fwd mac
>> Logical Core 1 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=1 (socket 0) -> TX P=0/Q=1 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=2 (socket 0) -> TX P=0/Q=2 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=3 (socket 0) -> TX P=0/Q=3 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 2 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 3 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=8 (socket 0) -> TX P=0/Q=8 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=9 (socket 0) -> TX P=0/Q=9 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=10 (socket 0) -> TX P=0/Q=10 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=11 (socket 0) -> TX P=0/Q=11 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 4 (socket 0) forwards packets on 4 streams:
>> RX P=0/Q=12 (socket 0) -> TX P=0/Q=12 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=13 (socket 0) -> TX P=0/Q=13 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=14 (socket 0) -> TX P=0/Q=14 (socket 0) peer=02:00:00:00:00:00 RX
>> P=0/Q=15 (socket 0) -> TX P=0/Q=15 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 5 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=4 (socket 0) -> TX P=0/Q=4 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 6 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=5 (socket 0) -> TX P=0/Q=5 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 7 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=6 (socket 0) -> TX P=0/Q=6 (socket 0) peer=02:00:00:00:00:00 Logical
>> Core 8 (socket 0) forwards packets on 1 streams:
>> RX P=0/Q=7 (socket 0) -> TX P=0/Q=7 (socket 0) peer=02:00:00:00:00:00
>>
>> Notice: number of rxq and txq in running cmdline are greater than used nb_tc.
>>
>> For the DCB forwarding test, each core is assigned on each traffic class and each
>> core is assigned a multi-stream. Therefore, 'nb_fwd_lcores'
>> value can be adjusted based on 'total_tc_num' in all forwarding ports.
>>
>> In addition, after operation of port stop/port start, forwarding configuration is
>> changed by rss_fwd_config_setup. In "start_port"
>> function, dcb_test is set to 1 based on dcb_config. So it also should be cleared
>> when dcb_config is 0.
>>
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/config.c  | 19 +++++++++++++++++++  app/test-pmd/testpmd.c |
>> 12 +++++++-----
>>   2 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>> 576d5ac..c89f8cd 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -2864,6 +2864,21 @@ rss_fwd_config_setup(void)
>>   	}
>>   }
>>
>> +static uint16_t
>> +get_fwd_port_total_tc_num(void)
>> +{
>> +	struct rte_eth_dcb_info dcb_info;
>> +	uint16_t total_tc_num = 0;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nb_fwd_ports; i++) {
>> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>> +		total_tc_num += dcb_info.nb_tcs;
>> +	}
>> +
>> +	return total_tc_num;
>> +}
> 
> It's only 3 lines. Is it really necessary to make it into a function which is not called by anyone else? A comment and the loop are enough.
> 
>> +
>>   /**
>>    * For the DCB forwarding test, each core is assigned on each traffic class.
>>    *
>> @@ -2883,12 +2898,16 @@ dcb_fwd_config_setup(void)
>>   	lcoreid_t  lc_id;
>>   	uint16_t nb_rx_queue, nb_tx_queue;
>>   	uint16_t i, j, k, sm_id = 0;
>> +	uint16_t total_tc_num = 0;
>>   	uint8_t tc = 0;
>>
>>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>   	cur_fwd_config.nb_fwd_streams =
>>   		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>> +	total_tc_num = get_fwd_port_total_tc_num();
>> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>
>>   	/* reinitialize forwarding streams */
>>   	init_fwd_streams();
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>> 1a57324..7eb810b 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>   	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>   	int peer_pi;
>>
>> -	if (dcb_test) {
>> -		dcb_test = 0;
>> -		dcb_config = 0;
>> -	}
>> -
>>   	if (port_id_is_invalid(pid, ENABLED_WARN))
>>   		return;
>>
>> +	/*
>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>> +	 * So it should be cleared when dcb_config is 0.
>> +	 */
>> +	if (dcb_config == 0)
>> +		dcb_test = 0;
>> +
> 
> I don't understand why are you changing this.
> dcb_test will only be set when dcb_config is 1 when starting ports. And both dcb_test and dcb_config will be cleared when stopping ports.
> So dcb will only affect when you set port dcb and then start port and when stop port dcb will be cleared.
> 
Yes, I think. The forwarding streams should not be changed from 
"dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is 
configured.
But, now, the logical codes do it when stopping ports and then starting 
ports.
> So what's the problem of original codes?
> 
> Your change will cause issues that there's no place to set dcb_config as 0. If you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
> 
As far as I know, the current testpmd only supports switching from the 
normal mode to the dcb mode, but does not support the reverse operation.
And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after 
config.
>>   	printf("Stopping ports...\n");
>>
>>   	RTE_ETH_FOREACH_DEV(pi) {
>> --
>> 2.7.4
> 
> .
> 

Re: [dpdk-dev] [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Tuesday, March 23, 2021 22:19
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB
> test
> 
<snip>
> >> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
> >>   	portid_t peer_pl[RTE_MAX_ETHPORTS];
> >>   	int peer_pi;
> >>
> >> -	if (dcb_test) {
> >> -		dcb_test = 0;
> >> -		dcb_config = 0;
> >> -	}
> >> -
> >>   	if (port_id_is_invalid(pid, ENABLED_WARN))
> >>   		return;
> >>
> >> +	/*
> >> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
> >> +	 * So it should be cleared when dcb_config is 0.
> >> +	 */
> >> +	if (dcb_config == 0)
> >> +		dcb_test = 0;
> >> +
> >
> > I don't understand why are you changing this.
> > dcb_test will only be set when dcb_config is 1 when starting ports. And both
> dcb_test and dcb_config will be cleared when stopping ports.
> > So dcb will only affect when you set port dcb and then start port and when
> stop port dcb will be cleared.
> >
> Yes, I think. The forwarding streams should not be changed from
> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is configured.
> But, now, the logical codes do it when stopping ports and then starting ports.
> > So what's the problem of original codes?
> >
> > Your change will cause issues that there's no place to set dcb_config as 0. If
> you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
> >
> As far as I know, the current testpmd only supports switching from the
> normal mode to the dcb mode, but does not support the reverse operation.
> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
> config.

You're not answering my questions. Why are you changing the behavior of testpmd?
Your change will make testpmd stay dcb mode once set dcb mode and can't go back to normal mode. If users want to go back to normal mode, he/she has to restart the whole testpmd.

It worked as you can set dcb mode and start port. After stopping port, if you still want dcb mode, you need to set dcb mode command again. But at least the old way won't break anything.
@Yigit, Ferruh Not sure which behavior is better, what do you think?

And @oulijun can you just answer all comments in one thread?

> >>   	printf("Stopping ports...\n");
> >>
> >>   	RTE_ETH_FOREACH_DEV(pi) {
> >> --
> >> 2.7.4
> >
> > .
> >

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/3/24 10:03, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Tuesday, March 23, 2021 22:19
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB
>> test
>>
> <snip>
>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>    	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>    	int peer_pi;
>>>>
>>>> -	if (dcb_test) {
>>>> -		dcb_test = 0;
>>>> -		dcb_config = 0;
>>>> -	}
>>>> -
>>>>    	if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>    		return;
>>>>
>>>> +	/*
>>>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>>>> +	 * So it should be cleared when dcb_config is 0.
>>>> +	 */
>>>> +	if (dcb_config == 0)
>>>> +		dcb_test = 0;
>>>> +
>>>
>>> I don't understand why are you changing this.
>>> dcb_test will only be set when dcb_config is 1 when starting ports. And both
>> dcb_test and dcb_config will be cleared when stopping ports.
>>> So dcb will only affect when you set port dcb and then start port and when
>> stop port dcb will be cleared.
>>>
>> Yes, I think. The forwarding streams should not be changed from
>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is configured.
>> But, now, the logical codes do it when stopping ports and then starting ports.
>>> So what's the problem of original codes?
>>>
>>> Your change will cause issues that there's no place to set dcb_config as 0. If
>> you config dcb, then it'll be always dcb mode unless restart the whole testpmd.
>>>
>> As far as I know, the current testpmd only supports switching from the
>> normal mode to the dcb mode, but does not support the reverse operation.
>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
>> config.
> 
> You're not answering my questions. Why are you changing the behavior of testpmd?
> Your change will make testpmd stay dcb mode once set dcb mode and can't go back to normal mode. If users want to go back to normal mode, he/she has to restart the whole testpmd.
> 
Yes. Testpmd and PMD driver are both in dcb mode after dcb info is 
configured. In my opinion, the 'dcb_test' flag can't be clear to go back 
to normal mode after
stopping port and then starting port. Because PMD driver is still dcb 
mode. If users want to go back it, users should disable dcb mode and 
enable RSS or other mode.

> It worked as you can set dcb mode and start port. After stopping port, if you still want dcb mode, you need to set dcb mode command again. But at least the old way won't break anything.
> @Yigit, Ferruh Not sure which behavior is better, what do you think?
> 
> And @oulijun can you just answer all comments in one thread?
> 
After stopping port, the 'dcb_test' flag is clear. At this moment, the 
dcb configuration in testpmd has not be changed.  users may not 
understand why the DCB mode needs to be reconfigured.
>>>>    	printf("Stopping ports...\n");
>>>>
>>>>    	RTE_ETH_FOREACH_DEV(pi) {
>>>> --
>>>> 2.7.4
>>>
>>> .
>>>
> _______________________________________________
> Linuxarm mailing list -- linuxarm@openeuler.org
> To unsubscribe send an email to linuxarm-leave@openeuler.org
> 

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Wednesday, March 24, 2021 21:40
> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
> <dev@dpdk.org>
> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
> configuration when DCB test
> 
> 
> 
> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
> >
> >
> >> -----Original Message-----
> >> From: oulijun <oulijun@huawei.com>
> >> Sent: Tuesday, March 23, 2021 22:19
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
> >> when DCB test
> >>
> > <snip>
> >>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
> >>>>    	portid_t peer_pl[RTE_MAX_ETHPORTS];
> >>>>    	int peer_pi;
> >>>>
> >>>> -	if (dcb_test) {
> >>>> -		dcb_test = 0;
> >>>> -		dcb_config = 0;
> >>>> -	}
> >>>> -
> >>>>    	if (port_id_is_invalid(pid, ENABLED_WARN))
> >>>>    		return;
> >>>>
> >>>> +	/*
> >>>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
> >>>> +	 * So it should be cleared when dcb_config is 0.
> >>>> +	 */
> >>>> +	if (dcb_config == 0)
> >>>> +		dcb_test = 0;
> >>>> +
> >>>
> >>> I don't understand why are you changing this.
> >>> dcb_test will only be set when dcb_config is 1 when starting ports.
> >>> And both
> >> dcb_test and dcb_config will be cleared when stopping ports.
> >>> So dcb will only affect when you set port dcb and then start port
> >>> and when
> >> stop port dcb will be cleared.
> >>>
> >> Yes, I think. The forwarding streams should not be changed from
> >> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
> configured.
> >> But, now, the logical codes do it when stopping ports and then starting ports.
> >>> So what's the problem of original codes?
> >>>
> >>> Your change will cause issues that there's no place to set
> >>> dcb_config as 0. If
> >> you config dcb, then it'll be always dcb mode unless restart the whole
> testpmd.
> >>>
> >> As far as I know, the current testpmd only supports switching from
> >> the normal mode to the dcb mode, but does not support the reverse
> operation.
> >> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
> >> config.
> >
> > You're not answering my questions. Why are you changing the behavior of
> testpmd?
> > Your change will make testpmd stay dcb mode once set dcb mode and can't go
> back to normal mode. If users want to go back to normal mode, he/she has to
> restart the whole testpmd.
> >
> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is configured.
> In my opinion, the 'dcb_test' flag can't be clear to go back to normal mode after
> stopping port and then starting port. Because PMD driver is still dcb mode. If
> users want to go back it, users should disable dcb mode and enable RSS or other
> mode.
> 
> > It worked as you can set dcb mode and start port. After stopping port, if you
> still want dcb mode, you need to set dcb mode command again. But at least the
> old way won't break anything.
> > @Yigit, Ferruh Not sure which behavior is better, what do you think?
> >
> > And @oulijun can you just answer all comments in one thread?
> >
> After stopping port, the 'dcb_test' flag is clear. At this moment, the dcb
> configuration in testpmd has not be changed.  users may not understand why
> the DCB mode needs to be reconfigured.

OK. You're right. There's no place writing port->dcb_flag back to 0.

> >>>>    	printf("Stopping ports...\n");
> >>>>
> >>>>    	RTE_ETH_FOREACH_DEV(pi) {
> >>>> --
> >>>> 2.7.4
> >>>
> >>> .
> >>>
> > _______________________________________________
> > Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
> > email to linuxarm-leave@openeuler.org
> >

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/3/25 10:21, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Wednesday, March 24, 2021 21:40
>> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
>> <dev@dpdk.org>
>> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
>> configuration when DCB test
>>
>>
>>
>> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Tuesday, March 23, 2021 22:19
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
>>>> when DCB test
>>>>
>>> <snip>
>>>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>>>     	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>>>     	int peer_pi;
>>>>>>
>>>>>> -	if (dcb_test) {
>>>>>> -		dcb_test = 0;
>>>>>> -		dcb_config = 0;
>>>>>> -	}
>>>>>> -
>>>>>>     	if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>>>     		return;
>>>>>>
>>>>>> +	/*
>>>>>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>>>>>> +	 * So it should be cleared when dcb_config is 0.
>>>>>> +	 */
>>>>>> +	if (dcb_config == 0)
>>>>>> +		dcb_test = 0;
>>>>>> +
>>>>>
>>>>> I don't understand why are you changing this.
>>>>> dcb_test will only be set when dcb_config is 1 when starting ports.
>>>>> And both
>>>> dcb_test and dcb_config will be cleared when stopping ports.
>>>>> So dcb will only affect when you set port dcb and then start port
>>>>> and when
>>>> stop port dcb will be cleared.
>>>>>
>>>> Yes, I think. The forwarding streams should not be changed from
>>>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
>> configured.
>>>> But, now, the logical codes do it when stopping ports and then starting ports.
>>>>> So what's the problem of original codes?
>>>>>
>>>>> Your change will cause issues that there's no place to set
>>>>> dcb_config as 0. If
>>>> you config dcb, then it'll be always dcb mode unless restart the whole
>> testpmd.
>>>>>
>>>> As far as I know, the current testpmd only supports switching from
>>>> the normal mode to the dcb mode, but does not support the reverse
>> operation.
>>>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
>>>> config.
>>>
>>> You're not answering my questions. Why are you changing the behavior of
>> testpmd?
>>> Your change will make testpmd stay dcb mode once set dcb mode and can't go
>> back to normal mode. If users want to go back to normal mode, he/she has to
>> restart the whole testpmd.
>>>
>> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is configured.
>> In my opinion, the 'dcb_test' flag can't be clear to go back to normal mode after
>> stopping port and then starting port. Because PMD driver is still dcb mode. If
>> users want to go back it, users should disable dcb mode and enable RSS or other
>> mode.
>>
>>> It worked as you can set dcb mode and start port. After stopping port, if you
>> still want dcb mode, you need to set dcb mode command again. But at least the
>> old way won't break anything.
>>> @Yigit, Ferruh Not sure which behavior is better, what do you think?
>>>
>>> And @oulijun can you just answer all comments in one thread?
>>>
>> After stopping port, the 'dcb_test' flag is clear. At this moment, the dcb
>> configuration in testpmd has not be changed.  users may not understand why
>> the DCB mode needs to be reconfigured.
> 
> OK. You're right. There's no place writing port->dcb_flag back to 0.
> 
Yes. Unless testpmd supports switching from DCB mode to other modes.
Do you have any other suggestions about this patch set, xiaoyun?
>>>>>>     	printf("Stopping ports...\n");
>>>>>>
>>>>>>     	RTE_ETH_FOREACH_DEV(pi) {
>>>>>> --
>>>>>> 2.7.4
>>>>>
>>>>> .
>>>>>
>>> _______________________________________________
>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
>>> email to linuxarm-leave@openeuler.org
>>>

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Ferruh Yigit]

On 3/25/2021 2:21 AM, Li, Xiaoyun wrote:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Wednesday, March 24, 2021 21:40
>> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
>> <dev@dpdk.org>
>> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
>> configuration when DCB test
>>
>>
>>
>> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Tuesday, March 23, 2021 22:19
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
>>>> when DCB test
>>>>
>>> <snip>
>>>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>>>     	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>>>     	int peer_pi;
>>>>>>
>>>>>> -	if (dcb_test) {
>>>>>> -		dcb_test = 0;
>>>>>> -		dcb_config = 0;
>>>>>> -	}
>>>>>> -
>>>>>>     	if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>>>     		return;
>>>>>>
>>>>>> +	/*
>>>>>> +	 * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>>>>>> +	 * So it should be cleared when dcb_config is 0.
>>>>>> +	 */
>>>>>> +	if (dcb_config == 0)
>>>>>> +		dcb_test = 0;
>>>>>> +
>>>>>
>>>>> I don't understand why are you changing this.
>>>>> dcb_test will only be set when dcb_config is 1 when starting ports.
>>>>> And both
>>>> dcb_test and dcb_config will be cleared when stopping ports.
>>>>> So dcb will only affect when you set port dcb and then start port
>>>>> and when
>>>> stop port dcb will be cleared.
>>>>>
>>>> Yes, I think. The forwarding streams should not be changed from
>>>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
>> configured.
>>>> But, now, the logical codes do it when stopping ports and then starting ports.
>>>>> So what's the problem of original codes?
>>>>>
>>>>> Your change will cause issues that there's no place to set
>>>>> dcb_config as 0. If
>>>> you config dcb, then it'll be always dcb mode unless restart the whole
>> testpmd.
>>>>>
>>>> As far as I know, the current testpmd only supports switching from
>>>> the normal mode to the dcb mode, but does not support the reverse
>> operation.
>>>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
>>>> config.
>>>
>>> You're not answering my questions. Why are you changing the behavior of
>> testpmd?
>>> Your change will make testpmd stay dcb mode once set dcb mode and can't go
>> back to normal mode. If users want to go back to normal mode, he/she has to
>> restart the whole testpmd.
>>>
>> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is configured.
>> In my opinion, the 'dcb_test' flag can't be clear to go back to normal mode after
>> stopping port and then starting port. Because PMD driver is still dcb mode. If
>> users want to go back it, users should disable dcb mode and enable RSS or other
>> mode.
>>
>>> It worked as you can set dcb mode and start port. After stopping port, if you
>> still want dcb mode, you need to set dcb mode command again. But at least the
>> old way won't break anything.
>>> @Yigit, Ferruh Not sure which behavior is better, what do you think?
>>>
>>> And @oulijun can you just answer all comments in one thread?
>>>
>> After stopping port, the 'dcb_test' flag is clear. At this moment, the dcb
>> configuration in testpmd has not be changed.  users may not understand why
>> the DCB mode needs to be reconfigured.
> 
> OK. You're right. There's no place writing port->dcb_flag back to 0.
> 

If there is no way to turn off the DCB, isn't this code logically dead? This 
code is run when "dcb_config == 0" but in that case 'dcb_test' is already 0.
If so what is the point of the code, can it be removed?

btw, do you know what 'dcb_test' does at all? It seems it is set when 
'dcb_config' set, and reset when 'dcb_config' reset.

>>>>>>     	printf("Stopping ports...\n");
>>>>>>
>>>>>>     	RTE_ETH_FOREACH_DEV(pi) {
>>>>>> --
>>>>>> 2.7.4
>>>>>
>>>>> .
>>>>>
>>> _______________________________________________
>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
>>> email to linuxarm-leave@openeuler.org
>>>

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/4/10 8:56, Ferruh Yigit 写道:
> On 3/25/2021 2:21 AM, Li, Xiaoyun wrote:
>>
>>
>>> -----Original Message-----
>>> From: oulijun <oulijun@huawei.com>
>>> Sent: Wednesday, March 24, 2021 21:40
>>> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
>>> <dev@dpdk.org>
>>> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
>>> configuration when DCB test
>>>
>>>
>>>
>>> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: oulijun <oulijun@huawei.com>
>>>>> Sent: Tuesday, March 23, 2021 22:19
>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>> <ferruh.yigit@intel.com>
>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
>>>>> when DCB test
>>>>>
>>>> <snip>
>>>>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>>>>         portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>>>>         int peer_pi;
>>>>>>>
>>>>>>> -    if (dcb_test) {
>>>>>>> -        dcb_test = 0;
>>>>>>> -        dcb_config = 0;
>>>>>>> -    }
>>>>>>> -
>>>>>>>         if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>>>>             return;
>>>>>>>
>>>>>>> +    /*
>>>>>>> +     * In "start_port" function, dcb_test is set to 1 based on 
>>>>>>> dcb_config.
>>>>>>> +     * So it should be cleared when dcb_config is 0.
>>>>>>> +     */
>>>>>>> +    if (dcb_config == 0)
>>>>>>> +        dcb_test = 0;
>>>>>>> +
>>>>>>
>>>>>> I don't understand why are you changing this.
>>>>>> dcb_test will only be set when dcb_config is 1 when starting ports.
>>>>>> And both
>>>>> dcb_test and dcb_config will be cleared when stopping ports.
>>>>>> So dcb will only affect when you set port dcb and then start port
>>>>>> and when
>>>>> stop port dcb will be cleared.
>>>>>>
>>>>> Yes, I think. The forwarding streams should not be changed from
>>>>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
>>> configured.
>>>>> But, now, the logical codes do it when stopping ports and then 
>>>>> starting ports.
>>>>>> So what's the problem of original codes?
>>>>>>
>>>>>> Your change will cause issues that there's no place to set
>>>>>> dcb_config as 0. If
>>>>> you config dcb, then it'll be always dcb mode unless restart the 
>>>>> whole
>>> testpmd.
>>>>>>
>>>>> As far as I know, the current testpmd only supports switching from
>>>>> the normal mode to the dcb mode, but does not support the reverse
>>> operation.
>>>>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
>>>>> config.
>>>>
>>>> You're not answering my questions. Why are you changing the 
>>>> behavior of
>>> testpmd?
>>>> Your change will make testpmd stay dcb mode once set dcb mode and 
>>>> can't go
>>> back to normal mode. If users want to go back to normal mode, he/she 
>>> has to
>>> restart the whole testpmd.
>>>>
>>> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is 
>>> configured.
>>> In my opinion, the 'dcb_test' flag can't be clear to go back to 
>>> normal mode after
>>> stopping port and then starting port. Because PMD driver is still 
>>> dcb mode. If
>>> users want to go back it, users should disable dcb mode and enable 
>>> RSS or other
>>> mode.
>>>
>>>> It worked as you can set dcb mode and start port. After stopping 
>>>> port, if you
>>> still want dcb mode, you need to set dcb mode command again. But at 
>>> least the
>>> old way won't break anything.
>>>> @Yigit, Ferruh Not sure which behavior is better, what do you think?
>>>>
>>>> And @oulijun can you just answer all comments in one thread?
>>>>
>>> After stopping port, the 'dcb_test' flag is clear. At this moment, 
>>> the dcb
>>> configuration in testpmd has not be changed.  users may not 
>>> understand why
>>> the DCB mode needs to be reconfigured.
>>
>> OK. You're right. There's no place writing port->dcb_flag back to 0.
>>
>
> If there is no way to turn off the DCB, isn't this code logically 
> dead? This code is run when "dcb_config == 0" but in that case 
> 'dcb_test' is already 0.
> If so what is the point of the code, can it be removed?
>
yes. Currently, it is a dead logic unless testpmd adds support for 
switching from DCB mode to other modes.
I think dcb_test is a flag at the packet forwarding layer in testpmd. 
The original purpose is to indicate that the current forwarding test is 
being performed in DCB mode.
> btw, do you know what 'dcb_test' does at all? It seems it is set when 
> 'dcb_config' set, and reset when 'dcb_config' reset.
>
In my opinion, it is only a global flag. During a DCB test, DCB must be 
configured on all forwarding ports.
>>>>>>>         printf("Stopping ports...\n");
>>>>>>>
>>>>>>>         RTE_ETH_FOREACH_DEV(pi) {
>>>>>>> -- 
>>>>>>> 2.7.4
>>>>>>
>>>>>> .
>>>>>>
>>>> _______________________________________________
>>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
>>>> email to linuxarm-leave@openeuler.org
>>>>
>
> .
>

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[Ferruh Yigit]

On 4/10/2021 3:58 AM, oulijun wrote:
> 
> 
> 在 2021/4/10 8:56, Ferruh Yigit 写道:
>> On 3/25/2021 2:21 AM, Li, Xiaoyun wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Wednesday, March 24, 2021 21:40
>>>> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
>>>> <dev@dpdk.org>
>>>> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
>>>> configuration when DCB test
>>>>
>>>>
>>>>
>>>> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: oulijun <oulijun@huawei.com>
>>>>>> Sent: Tuesday, March 23, 2021 22:19
>>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>>> <ferruh.yigit@intel.com>
>>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
>>>>>> when DCB test
>>>>>>
>>>>> <snip>
>>>>>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>>>>>         portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>>>>>         int peer_pi;
>>>>>>>>
>>>>>>>> -    if (dcb_test) {
>>>>>>>> -        dcb_test = 0;
>>>>>>>> -        dcb_config = 0;
>>>>>>>> -    }
>>>>>>>> -
>>>>>>>>         if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>>>>>             return;
>>>>>>>>
>>>>>>>> +    /*
>>>>>>>> +     * In "start_port" function, dcb_test is set to 1 based on dcb_config.
>>>>>>>> +     * So it should be cleared when dcb_config is 0.
>>>>>>>> +     */
>>>>>>>> +    if (dcb_config == 0)
>>>>>>>> +        dcb_test = 0;
>>>>>>>> +
>>>>>>>
>>>>>>> I don't understand why are you changing this.
>>>>>>> dcb_test will only be set when dcb_config is 1 when starting ports.
>>>>>>> And both
>>>>>> dcb_test and dcb_config will be cleared when stopping ports.
>>>>>>> So dcb will only affect when you set port dcb and then start port
>>>>>>> and when
>>>>>> stop port dcb will be cleared.
>>>>>>>
>>>>>> Yes, I think. The forwarding streams should not be changed from
>>>>>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
>>>> configured.
>>>>>> But, now, the logical codes do it when stopping ports and then starting 
>>>>>> ports.
>>>>>>> So what's the problem of original codes?
>>>>>>>
>>>>>>> Your change will cause issues that there's no place to set
>>>>>>> dcb_config as 0. If
>>>>>> you config dcb, then it'll be always dcb mode unless restart the whole
>>>> testpmd.
>>>>>>>
>>>>>> As far as I know, the current testpmd only supports switching from
>>>>>> the normal mode to the dcb mode, but does not support the reverse
>>>> operation.
>>>>>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 after
>>>>>> config.
>>>>>
>>>>> You're not answering my questions. Why are you changing the behavior of
>>>> testpmd?
>>>>> Your change will make testpmd stay dcb mode once set dcb mode and can't go
>>>> back to normal mode. If users want to go back to normal mode, he/she has to
>>>> restart the whole testpmd.
>>>>>
>>>> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is configured.
>>>> In my opinion, the 'dcb_test' flag can't be clear to go back to normal mode 
>>>> after
>>>> stopping port and then starting port. Because PMD driver is still dcb mode. If
>>>> users want to go back it, users should disable dcb mode and enable RSS or other
>>>> mode.
>>>>
>>>>> It worked as you can set dcb mode and start port. After stopping port, if you
>>>> still want dcb mode, you need to set dcb mode command again. But at least the
>>>> old way won't break anything.
>>>>> @Yigit, Ferruh Not sure which behavior is better, what do you think?
>>>>>
>>>>> And @oulijun can you just answer all comments in one thread?
>>>>>
>>>> After stopping port, the 'dcb_test' flag is clear. At this moment, the dcb
>>>> configuration in testpmd has not be changed.  users may not understand why
>>>> the DCB mode needs to be reconfigured.
>>>
>>> OK. You're right. There's no place writing port->dcb_flag back to 0.
>>>
>>
>> If there is no way to turn off the DCB, isn't this code logically dead? This 
>> code is run when "dcb_config == 0" but in that case 'dcb_test' is already 0.
>> If so what is the point of the code, can it be removed?
>>
> yes. Currently, it is a dead logic unless testpmd adds support for switching 
> from DCB mode to other modes.
> I think dcb_test is a flag at the packet forwarding layer in testpmd. The 
> original purpose is to indicate that the current forwarding test is being 
> performed in DCB mode.

can 'dcb_config' be sufficient on its own for this? so that we can remove 
'dcb_test' and simplify the logic.

>> btw, do you know what 'dcb_test' does at all? It seems it is set when 
>> 'dcb_config' set, and reset when 'dcb_config' reset.
>>
> In my opinion, it is only a global flag. During a DCB test, DCB must be 
> configured on all forwarding ports.
>>>>>>>>         printf("Stopping ports...\n");
>>>>>>>>
>>>>>>>>         RTE_ETH_FOREACH_DEV(pi) {
>>>>>>>> -- 
>>>>>>>> 2.7.4
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>> _______________________________________________
>>>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
>>>>> email to linuxarm-leave@openeuler.org
>>>>>
>>
>> .
>>
> 

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding configuration when DCB test

[oulijun]

在 2021/4/12 15:52, Ferruh Yigit 写道:
> On 4/10/2021 3:58 AM, oulijun wrote:
>>
>>
>> 在 2021/4/10 8:56, Ferruh Yigit 写道:
>>> On 3/25/2021 2:21 AM, Li, Xiaoyun wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: oulijun <oulijun@huawei.com>
>>>>> Sent: Wednesday, March 24, 2021 21:40
>>>>> To: linuxarm@openeuler.org; Li, Xiaoyun <xiaoyun.li@intel.com>; dev
>>>>> <dev@dpdk.org>
>>>>> Subject: Re: [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix forwarding
>>>>> configuration when DCB test
>>>>>
>>>>>
>>>>>
>>>>> 在 2021/3/24 10:03, Li, Xiaoyun 写道:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: oulijun <oulijun@huawei.com>
>>>>>>> Sent: Tuesday, March 23, 2021 22:19
>>>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>>>> <ferruh.yigit@intel.com>
>>>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>>>> Subject: Re: [PATCH 1/3] app/testpmd: fix forwarding configuration
>>>>>>> when DCB test
>>>>>>>
>>>>>> <snip>
>>>>>>>>> @@ -2707,14 +2707,16 @@ stop_port(portid_t pid)
>>>>>>>>>         portid_t peer_pl[RTE_MAX_ETHPORTS];
>>>>>>>>>         int peer_pi;
>>>>>>>>>
>>>>>>>>> -    if (dcb_test) {
>>>>>>>>> -        dcb_test = 0;
>>>>>>>>> -        dcb_config = 0;
>>>>>>>>> -    }
>>>>>>>>> -
>>>>>>>>>         if (port_id_is_invalid(pid, ENABLED_WARN))
>>>>>>>>>             return;
>>>>>>>>>
>>>>>>>>> +    /*
>>>>>>>>> +     * In "start_port" function, dcb_test is set to 1 based 
>>>>>>>>> on dcb_config.
>>>>>>>>> +     * So it should be cleared when dcb_config is 0.
>>>>>>>>> +     */
>>>>>>>>> +    if (dcb_config == 0)
>>>>>>>>> +        dcb_test = 0;
>>>>>>>>> +
>>>>>>>>
>>>>>>>> I don't understand why are you changing this.
>>>>>>>> dcb_test will only be set when dcb_config is 1 when starting 
>>>>>>>> ports.
>>>>>>>> And both
>>>>>>> dcb_test and dcb_config will be cleared when stopping ports.
>>>>>>>> So dcb will only affect when you set port dcb and then start port
>>>>>>>> and when
>>>>>>> stop port dcb will be cleared.
>>>>>>>>
>>>>>>> Yes, I think. The forwarding streams should not be changed from
>>>>>>> "dcb_fwd_config_setup" to "rss_fwd_config_setup" after dcb info is
>>>>> configured.
>>>>>>> But, now, the logical codes do it when stopping ports and then 
>>>>>>> starting ports.
>>>>>>>> So what's the problem of original codes?
>>>>>>>>
>>>>>>>> Your change will cause issues that there's no place to set
>>>>>>>> dcb_config as 0. If
>>>>>>> you config dcb, then it'll be always dcb mode unless restart the 
>>>>>>> whole
>>>>> testpmd.
>>>>>>>>
>>>>>>> As far as I know, the current testpmd only supports switching from
>>>>>>> the normal mode to the dcb mode, but does not support the reverse
>>>>> operation.
>>>>>>> And " dcb_config" is set to 1, and then "dcb_test" is set to 1 
>>>>>>> after
>>>>>>> config.
>>>>>>
>>>>>> You're not answering my questions. Why are you changing the 
>>>>>> behavior of
>>>>> testpmd?
>>>>>> Your change will make testpmd stay dcb mode once set dcb mode and 
>>>>>> can't go
>>>>> back to normal mode. If users want to go back to normal mode, 
>>>>> he/she has to
>>>>> restart the whole testpmd.
>>>>>>
>>>>> Yes. Testpmd and PMD driver are both in dcb mode after dcb info is 
>>>>> configured.
>>>>> In my opinion, the 'dcb_test' flag can't be clear to go back to 
>>>>> normal mode after
>>>>> stopping port and then starting port. Because PMD driver is still 
>>>>> dcb mode. If
>>>>> users want to go back it, users should disable dcb mode and enable 
>>>>> RSS or other
>>>>> mode.
>>>>>
>>>>>> It worked as you can set dcb mode and start port. After stopping 
>>>>>> port, if you
>>>>> still want dcb mode, you need to set dcb mode command again. But 
>>>>> at least the
>>>>> old way won't break anything.
>>>>>> @Yigit, Ferruh Not sure which behavior is better, what do you think?
>>>>>>
>>>>>> And @oulijun can you just answer all comments in one thread?
>>>>>>
>>>>> After stopping port, the 'dcb_test' flag is clear. At this moment, 
>>>>> the dcb
>>>>> configuration in testpmd has not be changed.  users may not 
>>>>> understand why
>>>>> the DCB mode needs to be reconfigured.
>>>>
>>>> OK. You're right. There's no place writing port->dcb_flag back to 0.
>>>>
>>>
>>> If there is no way to turn off the DCB, isn't this code logically 
>>> dead? This code is run when "dcb_config == 0" but in that case 
>>> 'dcb_test' is already 0.
>>> If so what is the point of the code, can it be removed?
>>>
>> yes. Currently, it is a dead logic unless testpmd adds support for 
>> switching from DCB mode to other modes.
>> I think dcb_test is a flag at the packet forwarding layer in testpmd. 
>> The original purpose is to indicate that the current forwarding test 
>> is being performed in DCB mode.
>
> can 'dcb_config' be sufficient on its own for this? so that we can 
> remove 'dcb_test' and simplify the logic.
>

I agree with your proposal. Because the 'dcb_flag' field in struct 
rte_port  indicates whether the current port is DCB, It is sufficient to 
have 'dcb_config' as a global variable to control the DCB test status.

ok，I will send V2 to update all of the previous discussions.
>>> btw, do you know what 'dcb_test' does at all? It seems it is set 
>>> when 'dcb_config' set, and reset when 'dcb_config' reset.
>>>
>> In my opinion, it is only a global flag. During a DCB test, DCB must 
>> be configured on all forwarding ports.
>>>>>>>>>         printf("Stopping ports...\n");
>>>>>>>>>
>>>>>>>>>         RTE_ETH_FOREACH_DEV(pi) {
>>>>>>>>> -- 
>>>>>>>>> 2.7.4
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe 
>>>>>> send an
>>>>>> email to linuxarm-leave@openeuler.org
>>>>>>
>>>
>>> .
>>>
>>
>
> .
>

[dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Lijun Ou]

From: Huisong Li <lihuisong@huawei.com>

The "fwd_config_setup()" function does release and apply for
memory of forwarding flows, and re-establish these streams when
rxq/txq or rxd/txd is changed. The function is also called by
"start_packet_forwarding()" when user executes "start" cmd.
All changes for rxq/txq or rxd/txd can be updated uniformly
when this command is executed. Therefore, it is a little
redundant in the "cmd_config_rx_tx_parsed" function.

In addition, the forwarding stream under one TC is configured
based on number of queues allocated to TC. And number of queues
allocated to TC is updated after calling  "rte_eth_dev_configure"
again. If the number of queues is reduced after configuring the
DCB, and then, release and apply for stream memory, and reinitialize
the forwarding stream under the DCB mode based on the old TC
information. As a result, null pointer may be accessed.

Like:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
port stop all
port config all rxq 8
port config all txq 8

At the moment, a segmentation fault occurs.

Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
V1->V2:
- use stream instead of flow
---
 app/test-pmd/cmdline.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4df0c32..e316f5c 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
 		return;
 	}
 
-	fwd_config_setup();
-
 	init_port_config();
 
 	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
-- 
2.7.4

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Li, Xiaoyun]

Hi

> -----Original Message-----
> From: Lijun Ou <oulijun@huawei.com>
> Sent: Friday, March 5, 2021 18:22
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> linuxarm@openeuler.org
> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx
> and Tx
> 
> From: Huisong Li <lihuisong@huawei.com>
> 

The commit message should be more simple and avoids grammar mistakes.

> The "fwd_config_setup()" function does release and apply for memory of
> forwarding flows, and re-establish these streams when rxq/txq or rxd/txd is
> changed. The function is also called by "start_packet_forwarding()" when user
> executes "start" cmd.
> All changes for rxq/txq or rxd/txd can be updated uniformly when this command
> is executed. Therefore, it is a little redundant in the "cmd_config_rx_tx_parsed"
> function.

It's not redundant. This command may configure number of rxq/txq. So the fwd streams map may change.
Then it's common to check the fwd streams after this command using "show config fwd".
If you remove this fwd stream update, users can't get the correct new fwd streams until they start the traffic.
But they may change a lot of things and want to check if the setting is correct before they start the traffic.

> 
> In addition, the forwarding stream under one TC is configured based on number
> of queues allocated to TC. And number of queues allocated to TC is updated
> after calling  "rte_eth_dev_configure"
> again. If the number of queues is reduced after configuring the DCB, and then,
> release and apply for stream memory, and reinitialize the forwarding stream
> under the DCB mode based on the old TC information. As a result, null pointer
> may be accessed.

I think you should add "rte_eth_dev_configure " into dcb_fwd_config_setup() before rte_eth_dev_get_dcb_info().

And the commit message should be similar like the following:
Segment fault might happen after configuring queue number to less because dcb_fwd_config_setup setup dcb based on old dcb info.
And dcb info can only update after rte_eth_dev_configure().
So this patch adds rte_eth_dev_configure() before rte_eth_dev_get_dcb_info() to get updated dcb info to fix this issue.

> 
> Like:
> set nbcore 4
> port stop all
> port config 0 dcb vt off 4 pfc on
> port start all
> port stop all
> port config all rxq 8
> port config all txq 8
> 
> At the moment, a segmentation fault occurs.
> 
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
> V1->V2:
> - use stream instead of flow
> ---
>  app/test-pmd/cmdline.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 4df0c32..e316f5c 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>  		return;
>  	}
> 
> -	fwd_config_setup();
> -
>  	init_port_config();
> 
>  	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> --
> 2.7.4

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/3/23 15:50, Li, Xiaoyun 写道:
> Hi
> 
>> -----Original Message-----
>> From: Lijun Ou <oulijun@huawei.com>
>> Sent: Friday, March 5, 2021 18:22
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>> linuxarm@openeuler.org
>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx
>> and Tx
>>
>> From: Huisong Li <lihuisong@huawei.com>
>>
> 
> The commit message should be more simple and avoids grammar mistakes.
> 
All right, I will simply it.
>> The "fwd_config_setup()" function does release and apply for memory of
>> forwarding flows, and re-establish these streams when rxq/txq or rxd/txd is
>> changed. The function is also called by "start_packet_forwarding()" when user
>> executes "start" cmd.
>> All changes for rxq/txq or rxd/txd can be updated uniformly when this command
>> is executed. Therefore, it is a little redundant in the "cmd_config_rx_tx_parsed"
>> function.
> 
> It's not redundant. This command may configure number of rxq/txq. So the fwd streams map may change.
> Then it's common to check the fwd streams after this command using "show config fwd".
> If you remove this fwd stream update, users can't get the correct new fwd streams until they start the traffic.
> But they may change a lot of things and want to check if the setting is correct before they start the traffic.
> 
Yes, you are right. It's really unfriendly.
>>
>> In addition, the forwarding stream under one TC is configured based on number
>> of queues allocated to TC. And number of queues allocated to TC is updated
>> after calling  "rte_eth_dev_configure"
>> again. If the number of queues is reduced after configuring the DCB, and then,
>> release and apply for stream memory, and reinitialize the forwarding stream
>> under the DCB mode based on the old TC information. As a result, null pointer
>> may be accessed.
> 
> I think you should add "rte_eth_dev_configure " into dcb_fwd_config_setup() before rte_eth_dev_get_dcb_info().
> 
> And the commit message should be similar like the following:
> Segment fault might happen after configuring queue number to less because dcb_fwd_config_setup setup dcb based on old dcb info.
> And dcb info can only update after rte_eth_dev_configure().
> So this patch adds rte_eth_dev_configure() before rte_eth_dev_get_dcb_info() to get updated dcb info to fix this issue.
> 
Thank you for your advice. But the above adjustments may still not work 
for some drivers. The mapping between queues and TCs
in these drivers is updated in the dev_start stage.

I have an idea. We can move fwd_config_setup() to start_port(), which is 
called by main() and after starting ports
This not only solves the segment fault, but also does not have the 
problem you mentioned above. I test it and it is ok.

What do you think, xiaoyun?


>>
>> Like:
>> set nbcore 4
>> port stop all
>> port config 0 dcb vt off 4 pfc on
>> port start all
>> port stop all
>> port config all rxq 8
>> port config all txq 8
>>
>> At the moment, a segmentation fault occurs.
>>
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>> V1->V2:
>> - use stream instead of flow
>> ---
>>   app/test-pmd/cmdline.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
>> 4df0c32..e316f5c 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>>   		return;
>>   	}
>>
>> -	fwd_config_setup();
>> -
>>   	init_port_config();
>>
>>   	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>> --
>> 2.7.4
> 
> .
> 

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Wednesday, March 24, 2021 09:01
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
> Rx and Tx
> 
> 
> 
> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
> > Hi
> >
> >> -----Original Message-----
> >> From: Lijun Ou <oulijun@huawei.com>
> >> Sent: Friday, March 5, 2021 18:22
> >> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >> linuxarm@openeuler.org
> >> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
> >> parsing Rx and Tx
> >>
> >> From: Huisong Li <lihuisong@huawei.com>
> >>
> >
> > The commit message should be more simple and avoids grammar mistakes.
> >
> All right, I will simply it.
> >> The "fwd_config_setup()" function does release and apply for memory
> >> of forwarding flows, and re-establish these streams when rxq/txq or
> >> rxd/txd is changed. The function is also called by
> >> "start_packet_forwarding()" when user executes "start" cmd.
> >> All changes for rxq/txq or rxd/txd can be updated uniformly when this
> >> command is executed. Therefore, it is a little redundant in the
> "cmd_config_rx_tx_parsed"
> >> function.
> >
> > It's not redundant. This command may configure number of rxq/txq. So the
> fwd streams map may change.
> > Then it's common to check the fwd streams after this command using "show
> config fwd".
> > If you remove this fwd stream update, users can't get the correct new fwd
> streams until they start the traffic.
> > But they may change a lot of things and want to check if the setting is correct
> before they start the traffic.
> >
> Yes, you are right. It's really unfriendly.
> >>
> >> In addition, the forwarding stream under one TC is configured based
> >> on number of queues allocated to TC. And number of queues allocated
> >> to TC is updated after calling  "rte_eth_dev_configure"
> >> again. If the number of queues is reduced after configuring the DCB,
> >> and then, release and apply for stream memory, and reinitialize the
> >> forwarding stream under the DCB mode based on the old TC information.
> >> As a result, null pointer may be accessed.
> >
> > I think you should add "rte_eth_dev_configure " into dcb_fwd_config_setup()
> before rte_eth_dev_get_dcb_info().
> >
> > And the commit message should be similar like the following:
> > Segment fault might happen after configuring queue number to less because
> dcb_fwd_config_setup setup dcb based on old dcb info.
> > And dcb info can only update after rte_eth_dev_configure().
> > So this patch adds rte_eth_dev_configure() before rte_eth_dev_get_dcb_info()
> to get updated dcb info to fix this issue.
> >
> Thank you for your advice. But the above adjustments may still not work for
> some drivers. The mapping between queues and TCs in these drivers is updated
> in the dev_start stage.
> 
> I have an idea. We can move fwd_config_setup() to start_port(), which is called
> by main() and after starting ports This not only solves the segment fault, but also
> does not have the problem you mentioned above. I test it and it is ok.
> 
> What do you think, xiaoyun?

How can you fix the issue I mentioned?
You still need to start port first to see the updated fwd config.
And for those drivers, why does the mapping has to be updated in dev_start stage?
What does it need? Can't it be moved to dev_configure?
> 
> 
> >>
> >> Like:
> >> set nbcore 4
> >> port stop all
> >> port config 0 dcb vt off 4 pfc on
> >> port start all
> >> port stop all
> >> port config all rxq 8
> >> port config all txq 8
> >>
> >> At the moment, a segmentation fault occurs.
> >>
> >> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >> ---
> >> V1->V2:
> >> - use stream instead of flow
> >> ---
> >>   app/test-pmd/cmdline.c | 2 --
> >>   1 file changed, 2 deletions(-)
> >>
> >> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> >> 4df0c32..e316f5c 100644
> >> --- a/app/test-pmd/cmdline.c
> >> +++ b/app/test-pmd/cmdline.c
> >> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> >>   		return;
> >>   	}
> >>
> >> -	fwd_config_setup();
> >> -
> >>   	init_port_config();
> >>
> >>   	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> >> --
> >> 2.7.4
> >
> > .
> >

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/3/24 9:44, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Wednesday, March 24, 2021 09:01
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
>> Rx and Tx
>>
>>
>>
>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Lijun Ou <oulijun@huawei.com>
>>>> Sent: Friday, March 5, 2021 18:22
>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>> linuxarm@openeuler.org
>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>> parsing Rx and Tx
>>>>
>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>
>>>
>>> The commit message should be more simple and avoids grammar mistakes.
>>>
>> All right, I will simply it.
>>>> The "fwd_config_setup()" function does release and apply for memory
>>>> of forwarding flows, and re-establish these streams when rxq/txq or
>>>> rxd/txd is changed. The function is also called by
>>>> "start_packet_forwarding()" when user executes "start" cmd.
>>>> All changes for rxq/txq or rxd/txd can be updated uniformly when this
>>>> command is executed. Therefore, it is a little redundant in the
>> "cmd_config_rx_tx_parsed"
>>>> function.
>>>
>>> It's not redundant. This command may configure number of rxq/txq. So the
>> fwd streams map may change.
>>> Then it's common to check the fwd streams after this command using "show
>> config fwd".
>>> If you remove this fwd stream update, users can't get the correct new fwd
>> streams until they start the traffic.
>>> But they may change a lot of things and want to check if the setting is correct
>> before they start the traffic.
>>>
>> Yes, you are right. It's really unfriendly.
>>>>
>>>> In addition, the forwarding stream under one TC is configured based
>>>> on number of queues allocated to TC. And number of queues allocated
>>>> to TC is updated after calling  "rte_eth_dev_configure"
>>>> again. If the number of queues is reduced after configuring the DCB,
>>>> and then, release and apply for stream memory, and reinitialize the
>>>> forwarding stream under the DCB mode based on the old TC information.
>>>> As a result, null pointer may be accessed.
>>>
>>> I think you should add "rte_eth_dev_configure " into dcb_fwd_config_setup()
>> before rte_eth_dev_get_dcb_info().
>>>
>>> And the commit message should be similar like the following:
>>> Segment fault might happen after configuring queue number to less because
>> dcb_fwd_config_setup setup dcb based on old dcb info.
>>> And dcb info can only update after rte_eth_dev_configure().
>>> So this patch adds rte_eth_dev_configure() before rte_eth_dev_get_dcb_info()
>> to get updated dcb info to fix this issue.
>>>
>> Thank you for your advice. But the above adjustments may still not work for
>> some drivers. The mapping between queues and TCs in these drivers is updated
>> in the dev_start stage.
>>
>> I have an idea. We can move fwd_config_setup() to start_port(), which is called
>> by main() and after starting ports This not only solves the segment fault, but also
>> does not have the problem you mentioned above. I test it and it is ok.
>>
>> What do you think, xiaoyun?
> 
> How can you fix the issue I mentioned?
> You still need to start port first to see the updated fwd config.
Yes. But it can make sure that users get the correct new fwd streams  
before executing the 'start' command.
> And for those drivers, why does the mapping has to be updated in dev_start stage?
> What does it need? Can't it be moved to dev_configure?
The framework does not require that the configuration parameters  
transferred by the dev_configure API must
be updated in the interface of driver. The driver can  verify the  
correctness of these parameters in the interface,
and then complete the update in the dev_start stage. It depends on the  
design and need of the driver. Maybe
it's more appropriate to put it in dev_configure, but now we can't ask  
all these drivers to modify the operation.
>>
>>
>>>>
>>>> Like:
>>>> set nbcore 4
>>>> port stop all
>>>> port config 0 dcb vt off 4 pfc on
>>>> port start all
>>>> port stop all
>>>> port config all rxq 8
>>>> port config all txq 8
>>>>
>>>> At the moment, a segmentation fault occurs.
>>>>
>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> ---
>>>> V1->V2:
>>>> - use stream instead of flow
>>>> ---
>>>>    app/test-pmd/cmdline.c | 2 --
>>>>    1 file changed, 2 deletions(-)
>>>>
>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
>>>> 4df0c32..e316f5c 100644
>>>> --- a/app/test-pmd/cmdline.c
>>>> +++ b/app/test-pmd/cmdline.c
>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>>>>    		return;
>>>>    	}
>>>>
>>>> -	fwd_config_setup();
>>>> -
>>>>    	init_port_config();
>>>>
>>>>    	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>>>> --
>>>> 2.7.4
>>>
>>> .
>>>
> .
> 

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Thursday, March 25, 2021 11:04
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
> Rx and Tx
> 
> 
> 
> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
> >
> >
> >> -----Original Message-----
> >> From: oulijun <oulijun@huawei.com>
> >> Sent: Wednesday, March 24, 2021 09:01
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
> >> parsing Rx and Tx
> >>
> >>
> >>
> >> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
> >>> Hi
> >>>
> >>>> -----Original Message-----
> >>>> From: Lijun Ou <oulijun@huawei.com>
> >>>> Sent: Friday, March 5, 2021 18:22
> >>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >>>> linuxarm@openeuler.org
> >>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
> >>>> parsing Rx and Tx
> >>>>
> >>>> From: Huisong Li <lihuisong@huawei.com>
> >>>>
> >>>
> >>> The commit message should be more simple and avoids grammar mistakes.
> >>>
> >> All right, I will simply it.
> >>>> The "fwd_config_setup()" function does release and apply for memory
> >>>> of forwarding flows, and re-establish these streams when rxq/txq or
> >>>> rxd/txd is changed. The function is also called by
> >>>> "start_packet_forwarding()" when user executes "start" cmd.
> >>>> All changes for rxq/txq or rxd/txd can be updated uniformly when
> >>>> this command is executed. Therefore, it is a little redundant in
> >>>> the
> >> "cmd_config_rx_tx_parsed"
> >>>> function.
> >>>
> >>> It's not redundant. This command may configure number of rxq/txq. So
> >>> the
> >> fwd streams map may change.
> >>> Then it's common to check the fwd streams after this command using
> >>> "show
> >> config fwd".
> >>> If you remove this fwd stream update, users can't get the correct
> >>> new fwd
> >> streams until they start the traffic.
> >>> But they may change a lot of things and want to check if the setting
> >>> is correct
> >> before they start the traffic.
> >>>
> >> Yes, you are right. It's really unfriendly.
> >>>>
> >>>> In addition, the forwarding stream under one TC is configured based
> >>>> on number of queues allocated to TC. And number of queues allocated
> >>>> to TC is updated after calling  "rte_eth_dev_configure"
> >>>> again. If the number of queues is reduced after configuring the
> >>>> DCB, and then, release and apply for stream memory, and
> >>>> reinitialize the forwarding stream under the DCB mode based on the old TC
> information.
> >>>> As a result, null pointer may be accessed.
> >>>
> >>> I think you should add "rte_eth_dev_configure " into
> >>> dcb_fwd_config_setup()
> >> before rte_eth_dev_get_dcb_info().
> >>>
> >>> And the commit message should be similar like the following:
> >>> Segment fault might happen after configuring queue number to less
> >>> because
> >> dcb_fwd_config_setup setup dcb based on old dcb info.
> >>> And dcb info can only update after rte_eth_dev_configure().
> >>> So this patch adds rte_eth_dev_configure() before
> >>> rte_eth_dev_get_dcb_info()
> >> to get updated dcb info to fix this issue.
> >>>
> >> Thank you for your advice. But the above adjustments may still not
> >> work for some drivers. The mapping between queues and TCs in these
> >> drivers is updated in the dev_start stage.
> >>
> >> I have an idea. We can move fwd_config_setup() to start_port(), which
> >> is called by main() and after starting ports This not only solves the
> >> segment fault, but also does not have the problem you mentioned above. I
> test it and it is ok.
> >>
> >> What do you think, xiaoyun?
> >
> > How can you fix the issue I mentioned?
> > You still need to start port first to see the updated fwd config.
> Yes. But it can make sure that users get the correct new fwd streams before
> executing the 'start' command.
> > And for those drivers, why does the mapping has to be updated in dev_start
> stage?
> > What does it need? Can't it be moved to dev_configure?
> The framework does not require that the configuration parameters transferred
> by the dev_configure API must be updated in the interface of driver. The driver
> can  verify the correctness of these parameters in the interface, and then
> complete the update in the dev_start stage. It depends on the design and need
> of the driver. Maybe it's more appropriate to put it in dev_configure, but now
> we can't ask all these drivers to modify the operation.

I still think it's driver's responsibility to configure DCB in dev_configure.

Calling fwd_config_setup here is because this command changes queue number. Users just change queue number so want to check fwd setup. It's a normal and reasonable behavior.
Starting port will be called in many situations. I don't think it's appropriate to call fwd_config_setup every time calling port_start. And you can't expect users know the fwd setup only change after port_start.

These are only my thoughts. If anyone else agrees you, they can give you ack.
> >>
> >>
> >>>>
> >>>> Like:
> >>>> set nbcore 4
> >>>> port stop all
> >>>> port config 0 dcb vt off 4 pfc on
> >>>> port start all
> >>>> port stop all
> >>>> port config all rxq 8
> >>>> port config all txq 8
> >>>>
> >>>> At the moment, a segmentation fault occurs.
> >>>>
> >>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
> >>>> settings")
> >>>> Cc: stable@dpdk.org
> >>>>
> >>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>>> ---
> >>>> V1->V2:
> >>>> - use stream instead of flow
> >>>> ---
> >>>>    app/test-pmd/cmdline.c | 2 --
> >>>>    1 file changed, 2 deletions(-)
> >>>>
> >>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> >>>> 4df0c32..e316f5c 100644
> >>>> --- a/app/test-pmd/cmdline.c
> >>>> +++ b/app/test-pmd/cmdline.c
> >>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> >>>>    		return;
> >>>>    	}
> >>>>
> >>>> -	fwd_config_setup();
> >>>> -
> >>>>    	init_port_config();
> >>>>
> >>>>    	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> >>>> --
> >>>> 2.7.4
> >>>
> >>> .
> >>>
> > .
> >

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/3/29 9:53, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Thursday, March 25, 2021 11:04
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
>> Rx and Tx
>>
>>
>>
>> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Wednesday, March 24, 2021 09:01
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>> parsing Rx and Tx
>>>>
>>>>
>>>>
>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
>>>>> Hi
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lijun Ou <oulijun@huawei.com>
>>>>>> Sent: Friday, March 5, 2021 18:22
>>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>>>> linuxarm@openeuler.org
>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>>>> parsing Rx and Tx
>>>>>>
>>>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>>>
>>>>>
>>>>> The commit message should be more simple and avoids grammar mistakes.
>>>>>
>>>> All right, I will simply it.
>>>>>> The "fwd_config_setup()" function does release and apply for memory
>>>>>> of forwarding flows, and re-establish these streams when rxq/txq or
>>>>>> rxd/txd is changed. The function is also called by
>>>>>> "start_packet_forwarding()" when user executes "start" cmd.
>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly when
>>>>>> this command is executed. Therefore, it is a little redundant in
>>>>>> the
>>>> "cmd_config_rx_tx_parsed"
>>>>>> function.
>>>>>
>>>>> It's not redundant. This command may configure number of rxq/txq. So
>>>>> the
>>>> fwd streams map may change.
>>>>> Then it's common to check the fwd streams after this command using
>>>>> "show
>>>> config fwd".
>>>>> If you remove this fwd stream update, users can't get the correct
>>>>> new fwd
>>>> streams until they start the traffic.
>>>>> But they may change a lot of things and want to check if the setting
>>>>> is correct
>>>> before they start the traffic.
>>>>>
>>>> Yes, you are right. It's really unfriendly.
>>>>>>
>>>>>> In addition, the forwarding stream under one TC is configured based
>>>>>> on number of queues allocated to TC. And number of queues allocated
>>>>>> to TC is updated after calling  "rte_eth_dev_configure"
>>>>>> again. If the number of queues is reduced after configuring the
>>>>>> DCB, and then, release and apply for stream memory, and
>>>>>> reinitialize the forwarding stream under the DCB mode based on the old TC
>> information.
>>>>>> As a result, null pointer may be accessed.
>>>>>
>>>>> I think you should add "rte_eth_dev_configure " into
>>>>> dcb_fwd_config_setup()
>>>> before rte_eth_dev_get_dcb_info().
>>>>>
>>>>> And the commit message should be similar like the following:
>>>>> Segment fault might happen after configuring queue number to less
>>>>> because
>>>> dcb_fwd_config_setup setup dcb based on old dcb info.
>>>>> And dcb info can only update after rte_eth_dev_configure().
>>>>> So this patch adds rte_eth_dev_configure() before
>>>>> rte_eth_dev_get_dcb_info()
>>>> to get updated dcb info to fix this issue.
>>>>>
>>>> Thank you for your advice. But the above adjustments may still not
>>>> work for some drivers. The mapping between queues and TCs in these
>>>> drivers is updated in the dev_start stage.
>>>>
>>>> I have an idea. We can move fwd_config_setup() to start_port(), which
>>>> is called by main() and after starting ports This not only solves the
>>>> segment fault, but also does not have the problem you mentioned above. I
>> test it and it is ok.
>>>>
>>>> What do you think, xiaoyun?
>>>
>>> How can you fix the issue I mentioned?
>>> You still need to start port first to see the updated fwd config.
>> Yes. But it can make sure that users get the correct new fwd streams before
>> executing the 'start' command.
>>> And for those drivers, why does the mapping has to be updated in dev_start
>> stage?
>>> What does it need? Can't it be moved to dev_configure?
>> The framework does not require that the configuration parameters transferred
>> by the dev_configure API must be updated in the interface of driver. The driver
>> can  verify the correctness of these parameters in the interface, and then
>> complete the update in the dev_start stage. It depends on the design and need
>> of the driver. Maybe it's more appropriate to put it in dev_configure, but now
>> we can't ask all these drivers to modify the operation.
> 
> I still think it's driver's responsibility to configure DCB in dev_configure.
> 
> Calling fwd_config_setup here is because this command changes queue number. Users just change queue number so want to check fwd setup. It's a normal and reasonable behavior.
> Starting port will be called in many situations. I don't think it's appropriate to call fwd_config_setup every time calling port_start. And you can't expect users know the fwd setup only change after port_start.
> 
> These are only my thoughts. If anyone else agrees you, they can give you ack.
>>>>
@Ferruh, what do you think?
Currently, both ixgbe and i40e also have this problem. Even if testpmd  
can be modified according to Xiaoyun's suggestion,
and the driver is not modified, this problem still exists in some  
drivers, such as ixgbe and hns3.
>>>>
>>>>>>
>>>>>> Like:
>>>>>> set nbcore 4
>>>>>> port stop all
>>>>>> port config 0 dcb vt off 4 pfc on
>>>>>> port start all
>>>>>> port stop all
>>>>>> port config all rxq 8
>>>>>> port config all txq 8
>>>>>>
>>>>>> At the moment, a segmentation fault occurs.
>>>>>>
>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
>>>>>> settings")
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>>>> ---
>>>>>> V1->V2:
>>>>>> - use stream instead of flow
>>>>>> ---
>>>>>>     app/test-pmd/cmdline.c | 2 --
>>>>>>     1 file changed, 2 deletions(-)
>>>>>>
>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
>>>>>> 4df0c32..e316f5c 100644
>>>>>> --- a/app/test-pmd/cmdline.c
>>>>>> +++ b/app/test-pmd/cmdline.c
>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>>>>>>     		return;
>>>>>>     	}
>>>>>>
>>>>>> -	fwd_config_setup();
>>>>>> -
>>>>>>     	init_port_config();
>>>>>>
>>>>>>     	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>>>>>> --
>>>>>> 2.7.4
>>>>>
>>>>> .
>>>>>
>>> .
>>>
> .
> 

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Friday, April 2, 2021 09:45
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
> Rx and Tx
> 
> 
> 
> 在 2021/3/29 9:53, Li, Xiaoyun 写道:
> >
> >
> >> -----Original Message-----
> >> From: oulijun <oulijun@huawei.com>
> >> Sent: Thursday, March 25, 2021 11:04
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
> >> parsing Rx and Tx
> >>
> >>
> >>
> >> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oulijun <oulijun@huawei.com>
> >>>> Sent: Wednesday, March 24, 2021 09:01
> >>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >>>> <ferruh.yigit@intel.com>
> >>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
> >>>> parsing Rx and Tx
> >>>>
> >>>>
> >>>>
> >>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
> >>>>> Hi
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Lijun Ou <oulijun@huawei.com>
> >>>>>> Sent: Friday, March 5, 2021 18:22
> >>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >>>>>> linuxarm@openeuler.org
> >>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
> >>>>>> parsing Rx and Tx
> >>>>>>
> >>>>>> From: Huisong Li <lihuisong@huawei.com>
> >>>>>>
> >>>>>
> >>>>> The commit message should be more simple and avoids grammar
> mistakes.
> >>>>>
> >>>> All right, I will simply it.
> >>>>>> The "fwd_config_setup()" function does release and apply for
> >>>>>> memory of forwarding flows, and re-establish these streams when
> >>>>>> rxq/txq or rxd/txd is changed. The function is also called by
> >>>>>> "start_packet_forwarding()" when user executes "start" cmd.
> >>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly when
> >>>>>> this command is executed. Therefore, it is a little redundant in
> >>>>>> the
> >>>> "cmd_config_rx_tx_parsed"
> >>>>>> function.
> >>>>>
> >>>>> It's not redundant. This command may configure number of rxq/txq.
> >>>>> So the
> >>>> fwd streams map may change.
> >>>>> Then it's common to check the fwd streams after this command using
> >>>>> "show
> >>>> config fwd".
> >>>>> If you remove this fwd stream update, users can't get the correct
> >>>>> new fwd
> >>>> streams until they start the traffic.
> >>>>> But they may change a lot of things and want to check if the
> >>>>> setting is correct
> >>>> before they start the traffic.
> >>>>>
> >>>> Yes, you are right. It's really unfriendly.
> >>>>>>
> >>>>>> In addition, the forwarding stream under one TC is configured
> >>>>>> based on number of queues allocated to TC. And number of queues
> >>>>>> allocated to TC is updated after calling  "rte_eth_dev_configure"
> >>>>>> again. If the number of queues is reduced after configuring the
> >>>>>> DCB, and then, release and apply for stream memory, and
> >>>>>> reinitialize the forwarding stream under the DCB mode based on
> >>>>>> the old TC
> >> information.
> >>>>>> As a result, null pointer may be accessed.
> >>>>>
> >>>>> I think you should add "rte_eth_dev_configure " into
> >>>>> dcb_fwd_config_setup()
> >>>> before rte_eth_dev_get_dcb_info().
> >>>>>
> >>>>> And the commit message should be similar like the following:
> >>>>> Segment fault might happen after configuring queue number to less
> >>>>> because
> >>>> dcb_fwd_config_setup setup dcb based on old dcb info.
> >>>>> And dcb info can only update after rte_eth_dev_configure().
> >>>>> So this patch adds rte_eth_dev_configure() before
> >>>>> rte_eth_dev_get_dcb_info()
> >>>> to get updated dcb info to fix this issue.
> >>>>>
> >>>> Thank you for your advice. But the above adjustments may still not
> >>>> work for some drivers. The mapping between queues and TCs in these
> >>>> drivers is updated in the dev_start stage.
> >>>>
> >>>> I have an idea. We can move fwd_config_setup() to start_port(),
> >>>> which is called by main() and after starting ports This not only
> >>>> solves the segment fault, but also does not have the problem you
> >>>> mentioned above. I
> >> test it and it is ok.
> >>>>
> >>>> What do you think, xiaoyun?
> >>>
> >>> How can you fix the issue I mentioned?
> >>> You still need to start port first to see the updated fwd config.
> >> Yes. But it can make sure that users get the correct new fwd streams
> >> before executing the 'start' command.
> >>> And for those drivers, why does the mapping has to be updated in
> >>> dev_start
> >> stage?
> >>> What does it need? Can't it be moved to dev_configure?
> >> The framework does not require that the configuration parameters
> >> transferred by the dev_configure API must be updated in the interface
> >> of driver. The driver can  verify the correctness of these parameters
> >> in the interface, and then complete the update in the dev_start
> >> stage. It depends on the design and need of the driver. Maybe it's
> >> more appropriate to put it in dev_configure, but now we can't ask all these
> drivers to modify the operation.
> >
> > I still think it's driver's responsibility to configure DCB in dev_configure.
> >
> > Calling fwd_config_setup here is because this command changes queue
> number. Users just change queue number so want to check fwd setup. It's a
> normal and reasonable behavior.
> > Starting port will be called in many situations. I don't think it's appropriate to
> call fwd_config_setup every time calling port_start. And you can't expect users
> know the fwd setup only change after port_start.
> >
> > These are only my thoughts. If anyone else agrees you, they can give you ack.
> >>>>
> @Ferruh, what do you think?
> Currently, both ixgbe and i40e also have this problem. Even if testpmd can be
> modified according to Xiaoyun's suggestion, and the driver is not modified, this
> problem still exists in some drivers, such as ixgbe and hns3.

NO. I40e and ixgbe DON'T have the issue.
I40e tc mapping is done in dev_configure.
ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure to get dcb_conf info. No matter you configure dcb or not, the mapping is always the same. You can check ixgbe_dev_get_dcb_info().

So for i40e and ixgbe, you only need to add dev_configure in dcb_fwd_config_setup().

> >>>>
> >>>>>>
> >>>>>> Like:
> >>>>>> set nbcore 4
> >>>>>> port stop all
> >>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all
> >>>>>> port config all rxq 8 port config all txq 8
> >>>>>>
> >>>>>> At the moment, a segmentation fault occurs.
> >>>>>>
> >>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
> >>>>>> settings")
> >>>>>> Cc: stable@dpdk.org
> >>>>>>
> >>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>>>>> ---
> >>>>>> V1->V2:
> >>>>>> - use stream instead of flow
> >>>>>> ---
> >>>>>>     app/test-pmd/cmdline.c | 2 --
> >>>>>>     1 file changed, 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> >>>>>> index 4df0c32..e316f5c 100644
> >>>>>> --- a/app/test-pmd/cmdline.c
> >>>>>> +++ b/app/test-pmd/cmdline.c
> >>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void
> *parsed_result,
> >>>>>>     		return;
> >>>>>>     	}
> >>>>>>
> >>>>>> -	fwd_config_setup();
> >>>>>> -
> >>>>>>     	init_port_config();
> >>>>>>
> >>>>>>     	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> >>>>>> --
> >>>>>> 2.7.4
> >>>>>
> >>>>> .
> >>>>>
> >>> .
> >>>
> > .
> >

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/4/2 10:33, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Friday, April 2, 2021 09:45
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing
>> Rx and Tx
>>
>>
>>
>> 在 2021/3/29 9:53, Li, Xiaoyun 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Thursday, March 25, 2021 11:04
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>> parsing Rx and Tx
>>>>
>>>>
>>>>
>>>> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: oulijun <oulijun@huawei.com>
>>>>>> Sent: Wednesday, March 24, 2021 09:01
>>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>>> <ferruh.yigit@intel.com>
>>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>>>> parsing Rx and Tx
>>>>>>
>>>>>>
>>>>>>
>>>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
>>>>>>> Hi
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lijun Ou <oulijun@huawei.com>
>>>>>>>> Sent: Friday, March 5, 2021 18:22
>>>>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>>>>>> linuxarm@openeuler.org
>>>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>>>>>> parsing Rx and Tx
>>>>>>>>
>>>>>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>>>>>
>>>>>>>
>>>>>>> The commit message should be more simple and avoids grammar
>> mistakes.
>>>>>>>
>>>>>> All right, I will simply it.
>>>>>>>> The "fwd_config_setup()" function does release and apply for
>>>>>>>> memory of forwarding flows, and re-establish these streams when
>>>>>>>> rxq/txq or rxd/txd is changed. The function is also called by
>>>>>>>> "start_packet_forwarding()" when user executes "start" cmd.
>>>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly when
>>>>>>>> this command is executed. Therefore, it is a little redundant in
>>>>>>>> the
>>>>>> "cmd_config_rx_tx_parsed"
>>>>>>>> function.
>>>>>>>
>>>>>>> It's not redundant. This command may configure number of rxq/txq.
>>>>>>> So the
>>>>>> fwd streams map may change.
>>>>>>> Then it's common to check the fwd streams after this command using
>>>>>>> "show
>>>>>> config fwd".
>>>>>>> If you remove this fwd stream update, users can't get the correct
>>>>>>> new fwd
>>>>>> streams until they start the traffic.
>>>>>>> But they may change a lot of things and want to check if the
>>>>>>> setting is correct
>>>>>> before they start the traffic.
>>>>>>>
>>>>>> Yes, you are right. It's really unfriendly.
>>>>>>>>
>>>>>>>> In addition, the forwarding stream under one TC is configured
>>>>>>>> based on number of queues allocated to TC. And number of queues
>>>>>>>> allocated to TC is updated after calling  "rte_eth_dev_configure"
>>>>>>>> again. If the number of queues is reduced after configuring the
>>>>>>>> DCB, and then, release and apply for stream memory, and
>>>>>>>> reinitialize the forwarding stream under the DCB mode based on
>>>>>>>> the old TC
>>>> information.
>>>>>>>> As a result, null pointer may be accessed.
>>>>>>>
>>>>>>> I think you should add "rte_eth_dev_configure " into
>>>>>>> dcb_fwd_config_setup()
>>>>>> before rte_eth_dev_get_dcb_info().
>>>>>>>
>>>>>>> And the commit message should be similar like the following:
>>>>>>> Segment fault might happen after configuring queue number to less
>>>>>>> because
>>>>>> dcb_fwd_config_setup setup dcb based on old dcb info.
>>>>>>> And dcb info can only update after rte_eth_dev_configure().
>>>>>>> So this patch adds rte_eth_dev_configure() before
>>>>>>> rte_eth_dev_get_dcb_info()
>>>>>> to get updated dcb info to fix this issue.
>>>>>>>
>>>>>> Thank you for your advice. But the above adjustments may still not
>>>>>> work for some drivers. The mapping between queues and TCs in these
>>>>>> drivers is updated in the dev_start stage.
>>>>>>
>>>>>> I have an idea. We can move fwd_config_setup() to start_port(),
>>>>>> which is called by main() and after starting ports This not only
>>>>>> solves the segment fault, but also does not have the problem you
>>>>>> mentioned above. I
>>>> test it and it is ok.
>>>>>>
>>>>>> What do you think, xiaoyun?
>>>>>
>>>>> How can you fix the issue I mentioned?
>>>>> You still need to start port first to see the updated fwd config.
>>>> Yes. But it can make sure that users get the correct new fwd streams
>>>> before executing the 'start' command.
>>>>> And for those drivers, why does the mapping has to be updated in
>>>>> dev_start
>>>> stage?
>>>>> What does it need? Can't it be moved to dev_configure?
>>>> The framework does not require that the configuration parameters
>>>> transferred by the dev_configure API must be updated in the interface
>>>> of driver. The driver can  verify the correctness of these parameters
>>>> in the interface, and then complete the update in the dev_start
>>>> stage. It depends on the design and need of the driver. Maybe it's
>>>> more appropriate to put it in dev_configure, but now we can't ask all these
>> drivers to modify the operation.
>>>
>>> I still think it's driver's responsibility to configure DCB in dev_configure.
>>>
>>> Calling fwd_config_setup here is because this command changes queue
>> number. Users just change queue number so want to check fwd setup. It's a
>> normal and reasonable behavior.
>>> Starting port will be called in many situations. I don't think it's appropriate to
>> call fwd_config_setup every time calling port_start. And you can't expect users
>> know the fwd setup only change after port_start.
>>>
>>> These are only my thoughts. If anyone else agrees you, they can give you ack.
>>>>>>
>> @Ferruh, what do you think?
>> Currently, both ixgbe and i40e also have this problem. Even if testpmd can be
>> modified according to Xiaoyun's suggestion, and the driver is not modified, this
>> problem still exists in some drivers, such as ixgbe and hns3.
> 
> NO. I40e and ixgbe DON'T have the issue.
> I40e tc mapping is done in dev_configure.
> ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure to get dcb_conf info. No matter you configure dcb or not, the mapping is always the same. You can check ixgbe_dev_get_dcb_info().
> 
> So for i40e and ixgbe, you only need to add dev_configure in dcb_fwd_config_setup().
> 
Hi, Xiaoyun,

The fwd_config_setup() is called when the port is in the stop state and 
start state.
When we run "start" cmd, all port are in the start state.  Namely,  we 
need to decide whether to call rte_eth_dev_configure() based on the 
state of all ports before rte_eth_dev_get_dcb_info() in 
dcb_fwd_config_setup().
Modify as follows:
@@ -1834,6 +1834,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
                 return;
         }

+       fwd_config_setup();
         init_port_config();

         cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index bd6ee8b..5981b50 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3179,7 +3179,24 @@ dcb_fwd_config_setup(void)
         uint16_t nb_rx_queue, nb_tx_queue;
         uint16_t i, j, k, sm_id = 0;
         uint16_t total_tc_num = 0;
+       struct rte_port *port;
         uint8_t tc = 0;
+       portid_t pid;
+       int ret;
+
+       if (all_ports_stopped()) {
+               /* re-configure the device after changing queue numbers. */
+               for (pid = 0; pid < nb_fwd_ports; pid++) {
+                       port = &ports[pid];
+                       ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
+                                                   &port->dev_conf);
+                       if (ret < 0) {
+                               printf("Failed to re-configure port %d, 
ret = %d.\n",
+                                       pid, ret);
+                               return;
+                       }
+               }
+       }

         cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
         cur_fwd_config.nb_fwd_ports = nb_fwd_ports;

But there's still no way to get away with the segment fault for ixgbe 
and i40e.
1/ For ixgbe, tc mapping is always fixed after DCB is configured.  If 
the number of queues is reduced, segment fault occur.
     Does it mean that the number of queues cannot be modified for ixgbe 
after DCB is configured?
2/ For i40e, it appears that the mapping between tc and queue is not 
updated after changing queue numbers. From i40e_vsi_config_tc(), its 
update seems to depend only on tc_map changes.

please check it?
>>>>>>
>>>>>>>>
>>>>>>>> Like:
>>>>>>>> set nbcore 4
>>>>>>>> port stop all
>>>>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all
>>>>>>>> port config all rxq 8 port config all txq 8
>>>>>>>>
>>>>>>>> At the moment, a segmentation fault occurs.
>>>>>>>>
>>>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
>>>>>>>> settings")
>>>>>>>> Cc: stable@dpdk.org
>>>>>>>>
>>>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>>>>>> ---
>>>>>>>> V1->V2:
>>>>>>>> - use stream instead of flow
>>>>>>>> ---
>>>>>>>>      app/test-pmd/cmdline.c | 2 --
>>>>>>>>      1 file changed, 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>>>>>>>> index 4df0c32..e316f5c 100644
>>>>>>>> --- a/app/test-pmd/cmdline.c
>>>>>>>> +++ b/app/test-pmd/cmdline.c
>>>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void
>> *parsed_result,
>>>>>>>>      		return;
>>>>>>>>      	}
>>>>>>>>
>>>>>>>> -	fwd_config_setup();
>>>>>>>> -
>>>>>>>>      	init_port_config();
>>>>>>>>
>>>>>>>>      	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>>>>>>>> --
>>>>>>>> 2.7.4
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>> .
>>>>>
>>> .
>>>
> _______________________________________________
> Linuxarm mailing list -- linuxarm@openeuler.org
> To unsubscribe send an email to linuxarm-leave@openeuler.org
> 

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Friday, April 9, 2021 14:10
> To: linuxarm@openeuler.org; dev <dev@dpdk.org>; Li, Xiaoyun
> <xiaoyun.li@intel.com>
> Subject: Re: [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding
> config from parsing Rx and Tx
> 
> 
> 
> 在 2021/4/2 10:33, Li, Xiaoyun 写道:
> >
> >
> >> -----Original Message-----
> >> From: oulijun <oulijun@huawei.com>
> >> Sent: Friday, April 2, 2021 09:45
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
> >> parsing Rx and Tx
> >>
> >>
> >>
> >> 在 2021/3/29 9:53, Li, Xiaoyun 写道:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oulijun <oulijun@huawei.com>
> >>>> Sent: Thursday, March 25, 2021 11:04
> >>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >>>> <ferruh.yigit@intel.com>
> >>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
> >>>> parsing Rx and Tx
> >>>>
> >>>>
> >>>>
> >>>> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: oulijun <oulijun@huawei.com>
> >>>>>> Sent: Wednesday, March 24, 2021 09:01
> >>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
> >>>>>> <ferruh.yigit@intel.com>
> >>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config
> >>>>>> from parsing Rx and Tx
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
> >>>>>>> Hi
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Lijun Ou <oulijun@huawei.com>
> >>>>>>>> Sent: Friday, March 5, 2021 18:22
> >>>>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >>>>>>>> linuxarm@openeuler.org
> >>>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
> >>>>>>>> parsing Rx and Tx
> >>>>>>>>
> >>>>>>>> From: Huisong Li <lihuisong@huawei.com>
> >>>>>>>>
> >>>>>>>
> >>>>>>> The commit message should be more simple and avoids grammar
> >> mistakes.
> >>>>>>>
> >>>>>> All right, I will simply it.
> >>>>>>>> The "fwd_config_setup()" function does release and apply for
> >>>>>>>> memory of forwarding flows, and re-establish these streams when
> >>>>>>>> rxq/txq or rxd/txd is changed. The function is also called by
> >>>>>>>> "start_packet_forwarding()" when user executes "start" cmd.
> >>>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly
> >>>>>>>> when this command is executed. Therefore, it is a little
> >>>>>>>> redundant in the
> >>>>>> "cmd_config_rx_tx_parsed"
> >>>>>>>> function.
> >>>>>>>
> >>>>>>> It's not redundant. This command may configure number of rxq/txq.
> >>>>>>> So the
> >>>>>> fwd streams map may change.
> >>>>>>> Then it's common to check the fwd streams after this command
> >>>>>>> using "show
> >>>>>> config fwd".
> >>>>>>> If you remove this fwd stream update, users can't get the
> >>>>>>> correct new fwd
> >>>>>> streams until they start the traffic.
> >>>>>>> But they may change a lot of things and want to check if the
> >>>>>>> setting is correct
> >>>>>> before they start the traffic.
> >>>>>>>
> >>>>>> Yes, you are right. It's really unfriendly.
> >>>>>>>>
> >>>>>>>> In addition, the forwarding stream under one TC is configured
> >>>>>>>> based on number of queues allocated to TC. And number of queues
> >>>>>>>> allocated to TC is updated after calling  "rte_eth_dev_configure"
> >>>>>>>> again. If the number of queues is reduced after configuring the
> >>>>>>>> DCB, and then, release and apply for stream memory, and
> >>>>>>>> reinitialize the forwarding stream under the DCB mode based on
> >>>>>>>> the old TC
> >>>> information.
> >>>>>>>> As a result, null pointer may be accessed.
> >>>>>>>
> >>>>>>> I think you should add "rte_eth_dev_configure " into
> >>>>>>> dcb_fwd_config_setup()
> >>>>>> before rte_eth_dev_get_dcb_info().
> >>>>>>>
> >>>>>>> And the commit message should be similar like the following:
> >>>>>>> Segment fault might happen after configuring queue number to
> >>>>>>> less because
> >>>>>> dcb_fwd_config_setup setup dcb based on old dcb info.
> >>>>>>> And dcb info can only update after rte_eth_dev_configure().
> >>>>>>> So this patch adds rte_eth_dev_configure() before
> >>>>>>> rte_eth_dev_get_dcb_info()
> >>>>>> to get updated dcb info to fix this issue.
> >>>>>>>
> >>>>>> Thank you for your advice. But the above adjustments may still
> >>>>>> not work for some drivers. The mapping between queues and TCs in
> >>>>>> these drivers is updated in the dev_start stage.
> >>>>>>
> >>>>>> I have an idea. We can move fwd_config_setup() to start_port(),
> >>>>>> which is called by main() and after starting ports This not only
> >>>>>> solves the segment fault, but also does not have the problem you
> >>>>>> mentioned above. I
> >>>> test it and it is ok.
> >>>>>>
> >>>>>> What do you think, xiaoyun?
> >>>>>
> >>>>> How can you fix the issue I mentioned?
> >>>>> You still need to start port first to see the updated fwd config.
> >>>> Yes. But it can make sure that users get the correct new fwd
> >>>> streams before executing the 'start' command.
> >>>>> And for those drivers, why does the mapping has to be updated in
> >>>>> dev_start
> >>>> stage?
> >>>>> What does it need? Can't it be moved to dev_configure?
> >>>> The framework does not require that the configuration parameters
> >>>> transferred by the dev_configure API must be updated in the
> >>>> interface of driver. The driver can  verify the correctness of
> >>>> these parameters in the interface, and then complete the update in
> >>>> the dev_start stage. It depends on the design and need of the
> >>>> driver. Maybe it's more appropriate to put it in dev_configure, but
> >>>> now we can't ask all these
> >> drivers to modify the operation.
> >>>
> >>> I still think it's driver's responsibility to configure DCB in dev_configure.
> >>>
> >>> Calling fwd_config_setup here is because this command changes queue
> >> number. Users just change queue number so want to check fwd setup.
> >> It's a normal and reasonable behavior.
> >>> Starting port will be called in many situations. I don't think it's
> >>> appropriate to
> >> call fwd_config_setup every time calling port_start. And you can't
> >> expect users know the fwd setup only change after port_start.
> >>>
> >>> These are only my thoughts. If anyone else agrees you, they can give you
> ack.
> >>>>>>
> >> @Ferruh, what do you think?
> >> Currently, both ixgbe and i40e also have this problem. Even if
> >> testpmd can be modified according to Xiaoyun's suggestion, and the
> >> driver is not modified, this problem still exists in some drivers, such as ixgbe
> and hns3.
> >
> > NO. I40e and ixgbe DON'T have the issue.
> > I40e tc mapping is done in dev_configure.
> > ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure
> to get dcb_conf info. No matter you configure dcb or not, the mapping is always
> the same. You can check ixgbe_dev_get_dcb_info().
> >
> > So for i40e and ixgbe, you only need to add dev_configure in
> dcb_fwd_config_setup().
> >
> Hi, Xiaoyun,
> 
> The fwd_config_setup() is called when the port is in the stop state and start
> state.
> When we run "start" cmd, all port are in the start state.  Namely,  we need to
> decide whether to call rte_eth_dev_configure() based on the state of all ports
> before rte_eth_dev_get_dcb_info() in dcb_fwd_config_setup().
> Modify as follows:
> @@ -1834,6 +1834,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>                  return;
>          }
> 
> +       fwd_config_setup();
>          init_port_config();
> 
>          cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); diff --git a/app/test-
> pmd/config.c b/app/test-pmd/config.c index bd6ee8b..5981b50 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -3179,7 +3179,24 @@ dcb_fwd_config_setup(void)
>          uint16_t nb_rx_queue, nb_tx_queue;
>          uint16_t i, j, k, sm_id = 0;
>          uint16_t total_tc_num = 0;
> +       struct rte_port *port;
>          uint8_t tc = 0;
> +       portid_t pid;
> +       int ret;
> +
> +       if (all_ports_stopped()) {
> +               /* re-configure the device after changing queue numbers. */
> +               for (pid = 0; pid < nb_fwd_ports; pid++) {
> +                       port = &ports[pid];
> +                       ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
> +                                                   &port->dev_conf);
> +                       if (ret < 0) {
> +                               printf("Failed to re-configure port %d,
> ret = %d.\n",
> +                                       pid, ret);
> +                               return;
> +                       }
> +               }
> +       }
> 
>          cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>          cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
> 
> But there's still no way to get away with the segment fault for ixgbe and i40e.
> 1/ For ixgbe, tc mapping is always fixed after DCB is configured.  If the number
> of queues is reduced, segment fault occur.
>      Does it mean that the number of queues cannot be modified for ixgbe after
> DCB is configured?
> 2/ For i40e, it appears that the mapping between tc and queue is not updated
> after changing queue numbers. From i40e_vsi_config_tc(), its update seems to
> depend only on tc_map changes.
> 
> please check it?

No.
After users config queue numbers using cmd "port config all rxq 4". It's normal that they may want to check what new fwd config will be like using "show config fwd"
So you should call fwd_config_setup() in cmd_config_rx_tx_parsed(). The ports are in stopped state.

dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first.
The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small).

For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not.
You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf.
So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info().

For i40e, dcb_setup is in dev_configure stage. i40e_dev_get_dcb_info() will get the correct info too.

> >>>>>>
> >>>>>>>>
> >>>>>>>> Like:
> >>>>>>>> set nbcore 4
> >>>>>>>> port stop all
> >>>>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all
> >>>>>>>> port config all rxq 8 port config all txq 8
> >>>>>>>>
> >>>>>>>> At the moment, a segmentation fault occurs.
> >>>>>>>>
> >>>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
> >>>>>>>> settings")
> >>>>>>>> Cc: stable@dpdk.org
> >>>>>>>>
> >>>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >>>>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>>>>>>> ---
> >>>>>>>> V1->V2:
> >>>>>>>> - use stream instead of flow
> >>>>>>>> ---
> >>>>>>>>      app/test-pmd/cmdline.c | 2 --
> >>>>>>>>      1 file changed, 2 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> >>>>>>>> index 4df0c32..e316f5c 100644
> >>>>>>>> --- a/app/test-pmd/cmdline.c
> >>>>>>>> +++ b/app/test-pmd/cmdline.c
> >>>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void
> >> *parsed_result,
> >>>>>>>>      		return;
> >>>>>>>>      	}
> >>>>>>>>
> >>>>>>>> -	fwd_config_setup();
> >>>>>>>> -
> >>>>>>>>      	init_port_config();
> >>>>>>>>
> >>>>>>>>      	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> >>>>>>>> --
> >>>>>>>> 2.7.4
> >>>>>>>
> >>>>>>> .
> >>>>>>>
> >>>>> .
> >>>>>
> >>> .
> >>>
> > _______________________________________________
> > Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
> > email to linuxarm-leave@openeuler.org
> >

Re: [dpdk-dev] [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/4/9 15:08, Li, Xiaoyun 写道:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Friday, April 9, 2021 14:10
>> To: linuxarm@openeuler.org; dev <dev@dpdk.org>; Li, Xiaoyun
>> <xiaoyun.li@intel.com>
>> Subject: Re: [Linuxarm] Re: [PATCH 2/3] app/testpmd: remove forwarding
>> config from parsing Rx and Tx
>>
>>
>>
>> 在 2021/4/2 10:33, Li, Xiaoyun 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: oulijun <oulijun@huawei.com>
>>>> Sent: Friday, April 2, 2021 09:45
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>> parsing Rx and Tx
>>>>
>>>>
>>>>
>>>> 在 2021/3/29 9:53, Li, Xiaoyun 写道:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: oulijun <oulijun@huawei.com>
>>>>>> Sent: Thursday, March 25, 2021 11:04
>>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>>> <ferruh.yigit@intel.com>
>>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>>>> parsing Rx and Tx
>>>>>>
>>>>>>
>>>>>>
>>>>>> 在 2021/3/24 9:44, Li, Xiaoyun 写道:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: oulijun <oulijun@huawei.com>
>>>>>>>> Sent: Wednesday, March 24, 2021 09:01
>>>>>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
>>>>>>>> <ferruh.yigit@intel.com>
>>>>>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>>>>>> Subject: Re: [PATCH 2/3] app/testpmd: remove forwarding config
>>>>>>>> from parsing Rx and Tx
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 在 2021/3/23 15:50, Li, Xiaoyun 写道:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Lijun Ou <oulijun@huawei.com>
>>>>>>>>>> Sent: Friday, March 5, 2021 18:22
>>>>>>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>>>>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>>>>>>>> linuxarm@openeuler.org
>>>>>>>>>> Subject: [PATCH 2/3] app/testpmd: remove forwarding config from
>>>>>>>>>> parsing Rx and Tx
>>>>>>>>>>
>>>>>>>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The commit message should be more simple and avoids grammar
>>>> mistakes.
>>>>>>>>>
>>>>>>>> All right, I will simply it.
>>>>>>>>>> The "fwd_config_setup()" function does release and apply for
>>>>>>>>>> memory of forwarding flows, and re-establish these streams when
>>>>>>>>>> rxq/txq or rxd/txd is changed. The function is also called by
>>>>>>>>>> "start_packet_forwarding()" when user executes "start" cmd.
>>>>>>>>>> All changes for rxq/txq or rxd/txd can be updated uniformly
>>>>>>>>>> when this command is executed. Therefore, it is a little
>>>>>>>>>> redundant in the
>>>>>>>> "cmd_config_rx_tx_parsed"
>>>>>>>>>> function.
>>>>>>>>>
>>>>>>>>> It's not redundant. This command may configure number of rxq/txq.
>>>>>>>>> So the
>>>>>>>> fwd streams map may change.
>>>>>>>>> Then it's common to check the fwd streams after this command
>>>>>>>>> using "show
>>>>>>>> config fwd".
>>>>>>>>> If you remove this fwd stream update, users can't get the
>>>>>>>>> correct new fwd
>>>>>>>> streams until they start the traffic.
>>>>>>>>> But they may change a lot of things and want to check if the
>>>>>>>>> setting is correct
>>>>>>>> before they start the traffic.
>>>>>>>>>
>>>>>>>> Yes, you are right. It's really unfriendly.
>>>>>>>>>>
>>>>>>>>>> In addition, the forwarding stream under one TC is configured
>>>>>>>>>> based on number of queues allocated to TC. And number of queues
>>>>>>>>>> allocated to TC is updated after calling  "rte_eth_dev_configure"
>>>>>>>>>> again. If the number of queues is reduced after configuring the
>>>>>>>>>> DCB, and then, release and apply for stream memory, and
>>>>>>>>>> reinitialize the forwarding stream under the DCB mode based on
>>>>>>>>>> the old TC
>>>>>> information.
>>>>>>>>>> As a result, null pointer may be accessed.
>>>>>>>>>
>>>>>>>>> I think you should add "rte_eth_dev_configure " into
>>>>>>>>> dcb_fwd_config_setup()
>>>>>>>> before rte_eth_dev_get_dcb_info().
>>>>>>>>>
>>>>>>>>> And the commit message should be similar like the following:
>>>>>>>>> Segment fault might happen after configuring queue number to
>>>>>>>>> less because
>>>>>>>> dcb_fwd_config_setup setup dcb based on old dcb info.
>>>>>>>>> And dcb info can only update after rte_eth_dev_configure().
>>>>>>>>> So this patch adds rte_eth_dev_configure() before
>>>>>>>>> rte_eth_dev_get_dcb_info()
>>>>>>>> to get updated dcb info to fix this issue.
>>>>>>>>>
>>>>>>>> Thank you for your advice. But the above adjustments may still
>>>>>>>> not work for some drivers. The mapping between queues and TCs in
>>>>>>>> these drivers is updated in the dev_start stage.
>>>>>>>>
>>>>>>>> I have an idea. We can move fwd_config_setup() to start_port(),
>>>>>>>> which is called by main() and after starting ports This not only
>>>>>>>> solves the segment fault, but also does not have the problem you
>>>>>>>> mentioned above. I
>>>>>> test it and it is ok.
>>>>>>>>
>>>>>>>> What do you think, xiaoyun?
>>>>>>>
>>>>>>> How can you fix the issue I mentioned?
>>>>>>> You still need to start port first to see the updated fwd config.
>>>>>> Yes. But it can make sure that users get the correct new fwd
>>>>>> streams before executing the 'start' command.
>>>>>>> And for those drivers, why does the mapping has to be updated in
>>>>>>> dev_start
>>>>>> stage?
>>>>>>> What does it need? Can't it be moved to dev_configure?
>>>>>> The framework does not require that the configuration parameters
>>>>>> transferred by the dev_configure API must be updated in the
>>>>>> interface of driver. The driver can  verify the correctness of
>>>>>> these parameters in the interface, and then complete the update in
>>>>>> the dev_start stage. It depends on the design and need of the
>>>>>> driver. Maybe it's more appropriate to put it in dev_configure, but
>>>>>> now we can't ask all these
>>>> drivers to modify the operation.
>>>>>
>>>>> I still think it's driver's responsibility to configure DCB in dev_configure.
>>>>>
>>>>> Calling fwd_config_setup here is because this command changes queue
>>>> number. Users just change queue number so want to check fwd setup.
>>>> It's a normal and reasonable behavior.
>>>>> Starting port will be called in many situations. I don't think it's
>>>>> appropriate to
>>>> call fwd_config_setup every time calling port_start. And you can't
>>>> expect users know the fwd setup only change after port_start.
>>>>>
>>>>> These are only my thoughts. If anyone else agrees you, they can give you
>> ack.
>>>>>>>>
>>>> @Ferruh, what do you think?
>>>> Currently, both ixgbe and i40e also have this problem. Even if
>>>> testpmd can be modified according to Xiaoyun's suggestion, and the
>>>> driver is not modified, this problem still exists in some drivers, such as ixgbe
>> and hns3.
>>>
>>> NO. I40e and ixgbe DON'T have the issue.
>>> I40e tc mapping is done in dev_configure.
>>> ixgbe tc mapping is always fixed due to hw design. It only needs dev_configure
>> to get dcb_conf info. No matter you configure dcb or not, the mapping is always
>> the same. You can check ixgbe_dev_get_dcb_info().
>>>
>>> So for i40e and ixgbe, you only need to add dev_configure in
>> dcb_fwd_config_setup().
>>>
>> Hi, Xiaoyun,
>>
>> The fwd_config_setup() is called when the port is in the stop state and start
>> state.
>> When we run "start" cmd, all port are in the start state.  Namely,  we need to
>> decide whether to call rte_eth_dev_configure() based on the state of all ports
>> before rte_eth_dev_get_dcb_info() in dcb_fwd_config_setup().
>> Modify as follows:
>> @@ -1834,6 +1834,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>>                   return;
>>           }
>>
>> +       fwd_config_setup();
>>           init_port_config();
>>
>>           cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1); diff --git a/app/test-
>> pmd/config.c b/app/test-pmd/config.c index bd6ee8b..5981b50 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -3179,7 +3179,24 @@ dcb_fwd_config_setup(void)
>>           uint16_t nb_rx_queue, nb_tx_queue;
>>           uint16_t i, j, k, sm_id = 0;
>>           uint16_t total_tc_num = 0;
>> +       struct rte_port *port;
>>           uint8_t tc = 0;
>> +       portid_t pid;
>> +       int ret;
>> +
>> +       if (all_ports_stopped()) {
>> +               /* re-configure the device after changing queue numbers. */
>> +               for (pid = 0; pid < nb_fwd_ports; pid++) {
>> +                       port = &ports[pid];
>> +                       ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
>> +                                                   &port->dev_conf);
>> +                       if (ret < 0) {
>> +                               printf("Failed to re-configure port %d,
>> ret = %d.\n",
>> +                                       pid, ret);
>> +                               return;
>> +                       }
>> +               }
>> +       }
>>
>>           cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>           cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>
>> But there's still no way to get away with the segment fault for ixgbe and i40e.
>> 1/ For ixgbe, tc mapping is always fixed after DCB is configured.  If the number
>> of queues is reduced, segment fault occur.
>>       Does it mean that the number of queues cannot be modified for ixgbe after
>> DCB is configured?
>> 2/ For i40e, it appears that the mapping between tc and queue is not updated
>> after changing queue numbers. From i40e_vsi_config_tc(), its update seems to
>> depend only on tc_map changes.
>>
>> please check it?
> 
> No.
> After users config queue numbers using cmd "port config all rxq 4". It's normal that they may want to check what new fwd config will be like using "show config fwd"
> So you should call fwd_config_setup() in cmd_config_rx_tx_parsed(). The ports are in stopped state.
> 
I see. The current modification has rolled back this behavior.

dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to 
get the dcb info first.
The segment fault happens because rte_eth_dev_get_dcb_info() get the 
wrong info based on old queue numbers (new queue number is small).
> dcb_fwd_config_setup() will call rte_eth_dev_get_dcb_info() at first to get the dcb info first.
> The segment fault happens because rte_eth_dev_get_dcb_info() get the wrong info based on old queue numbers (new queue number is small).
> 
Yes!  Currently, calling dev_configure at first in 
dcb_fwd_config_setup() is to update tc and queue mapping because of the 
change of queue number, so that testpmd can get  valid the dcb info by 
rte_eth_dev_get_dcb_info().

For ixgbe, The fixed mapping means for maximum queue numbers for example 
128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed 
values. It's just you enable which queues or not.
You can change queue number as you want. In dev_start stage, tc will 
actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf 
which info is included in dev_conf.
So for ixgbe, you only need to call dev_configure to update the new 
dcb_rx_conf for get_dcb_info().
> For ixgbe, The fixed mapping means for maximum queue numbers for example 128 queues. Each queue and tc mapping is fixed to fill to hw. Fixed values. It's just you enable which queues or not.
> You can change queue number as you want. In dev_start stage, tc will actually take effect. get_dcb_info() only needs rx_adv_conf.dcb_rx_conf which info is included in dev_conf.
> So for ixgbe, you only need to call dev_configure to update the new dcb_rx_conf for get_dcb_info().
> 
> For i40e, dcb_setup is in dev_configure stage. i40e_dev_get_dcb_info() will get the correct info too.
> 
The mapping for i40e is really updated in dev_configure. However, if the 
tc_map in i40e_vsi_config_tc() does not change, it seems that the 
mapping will not be updated.
Namely, This mapping can not be remodified due to queue count changes.
Maybe it is a bug for i40e.

I think this suggestion is reasonable. It's just that I think ixgbe and 
i40e may have the above issues.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Like:
>>>>>>>>>> set nbcore 4
>>>>>>>>>> port stop all
>>>>>>>>>> port config 0 dcb vt off 4 pfc on port start all port stop all
>>>>>>>>>> port config all rxq 8 port config all txq 8
>>>>>>>>>>
>>>>>>>>>> At the moment, a segmentation fault occurs.
>>>>>>>>>>
>>>>>>>>>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration
>>>>>>>>>> settings")
>>>>>>>>>> Cc: stable@dpdk.org
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>>>>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>>>>>>>> ---
>>>>>>>>>> V1->V2:
>>>>>>>>>> - use stream instead of flow
>>>>>>>>>> ---
>>>>>>>>>>       app/test-pmd/cmdline.c | 2 --
>>>>>>>>>>       1 file changed, 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>>>>>>>>>> index 4df0c32..e316f5c 100644
>>>>>>>>>> --- a/app/test-pmd/cmdline.c
>>>>>>>>>> +++ b/app/test-pmd/cmdline.c
>>>>>>>>>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void
>>>> *parsed_result,
>>>>>>>>>>       		return;
>>>>>>>>>>       	}
>>>>>>>>>>
>>>>>>>>>> -	fwd_config_setup();
>>>>>>>>>> -
>>>>>>>>>>       	init_port_config();
>>>>>>>>>>
>>>>>>>>>>       	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>>>>>>>>>> --
>>>>>>>>>> 2.7.4
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>> .
>>>>>>>
>>>>> .
>>>>>
>>> _______________________________________________
>>> Linuxarm mailing list -- linuxarm@openeuler.org To unsubscribe send an
>>> email to linuxarm-leave@openeuler.org
>>>

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[Ferruh Yigit]

On 3/5/2021 10:22 AM, Lijun Ou wrote:
> From: Huisong Li <lihuisong@huawei.com>
> 
> The "fwd_config_setup()" function does release and apply for
> memory of forwarding flows, and re-establish these streams when
> rxq/txq or rxd/txd is changed. The function is also called by
> "start_packet_forwarding()" when user executes "start" cmd.
> All changes for rxq/txq or rxd/txd can be updated uniformly
> when this command is executed. Therefore, it is a little
> redundant in the "cmd_config_rx_tx_parsed" function.
> 
> In addition, the forwarding stream under one TC is configured
> based on number of queues allocated to TC. And number of queues
> allocated to TC is updated after calling  "rte_eth_dev_configure"
> again. If the number of queues is reduced after configuring the
> DCB, and then, release and apply for stream memory, and reinitialize
> the forwarding stream under the DCB mode based on the old TC
> information. As a result, null pointer may be accessed.
> 
> Like:
> set nbcore 4
> port stop all
> port config 0 dcb vt off 4 pfc on
> port start all
> port stop all
> port config all rxq 8
> port config all txq 8
> 
> At the moment, a segmentation fault occurs.
> 

Hi Lijun, Xiaoyun,

I read the thread and checked the code, but still I am not completely clear with 
the dcp implementation in testpmd.

But the "dcb_config = 0" in the 'stop_port()' that has been removed in the patch 
1/3 seems preventing these kind of config combination, with implicitly resetting 
the dcb feature with port stop.

What do you think just have the number of forwarding cores adjustment change in 
the patch 1/3, and keep the 'stop_port()' as it is, will it solve this problem, 
and how acceptable it will be do you think?

> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
> V1->V2:
> - use stream instead of flow
> ---
>   app/test-pmd/cmdline.c | 2 --
>   1 file changed, 2 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 4df0c32..e316f5c 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>   		return;
>   	}
>   
> -	fwd_config_setup();
> -
>   	init_port_config();
>   
>   	cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
> 

Re: [dpdk-dev] [PATCH 2/3] app/testpmd: remove forwarding config from parsing Rx and Tx

[oulijun]

在 2021/4/12 18:35, Ferruh Yigit 写道:
> On 3/5/2021 10:22 AM, Lijun Ou wrote:
>> From: Huisong Li <lihuisong@huawei.com>
>>
>> The "fwd_config_setup()" function does release and apply for
>> memory of forwarding flows, and re-establish these streams when
>> rxq/txq or rxd/txd is changed. The function is also called by
>> "start_packet_forwarding()" when user executes "start" cmd.
>> All changes for rxq/txq or rxd/txd can be updated uniformly
>> when this command is executed. Therefore, it is a little
>> redundant in the "cmd_config_rx_tx_parsed" function.
>>
>> In addition, the forwarding stream under one TC is configured
>> based on number of queues allocated to TC. And number of queues
>> allocated to TC is updated after calling  "rte_eth_dev_configure"
>> again. If the number of queues is reduced after configuring the
>> DCB, and then, release and apply for stream memory, and reinitialize
>> the forwarding stream under the DCB mode based on the old TC
>> information. As a result, null pointer may be accessed.
>>
>> Like:
>> set nbcore 4
>> port stop all
>> port config 0 dcb vt off 4 pfc on
>> port start all
>> port stop all
>> port config all rxq 8
>> port config all txq 8
>>
>> At the moment, a segmentation fault occurs.
>>
> 
> Hi Lijun, Xiaoyun,
> 
> I read the thread and checked the code, but still I am not completely 
> clear with the dcp implementation in testpmd.
> 
> But the "dcb_config = 0" in the 'stop_port()' that has been removed in 
> the patch 1/3 seems preventing these kind of config combination, with 
> implicitly resetting the dcb feature with port stop.
> 
> What do you think just have the number of forwarding cores adjustment 
> change in the patch 1/3, and keep the 'stop_port()' as it is, will it 
> solve this problem, and how acceptable it will be do you think?
> 
I think it might be more appropriate to follow the discussion with Xiao 
Yun, since it does have problems.

In addition, I found another problem. Before calling 
dcb_fwd_config_setup(), testpmd must ensure that all ports have been 
configured with dcb.
Let's look at the next V3.
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>> V1->V2:
>> - use stream instead of flow
>> ---
>>   app/test-pmd/cmdline.c | 2 --
>>   1 file changed, 2 deletions(-)
>>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>> index 4df0c32..e316f5c 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -1837,8 +1837,6 @@ cmd_config_rx_tx_parsed(void *parsed_result,
>>           return;
>>       }
>> -    fwd_config_setup();
>> -
>>       init_port_config();
>>       cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
>>
> 
> .
> 

[dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Lijun Ou]

From: Hongbo Zheng <zhenghongbo3@huawei.com>

In testpmd, when we input "show config rxtx", we can see like this:

1: testpmd> show config rxtx
2:   io packet forwarding packets/burst=32
3:   nb forwarding cores=1 - nb forwarding ports=1
4:   port 0: RX queue number: 1 Tx queue number: 1
5:     Rx offloads=0x0 Tx offloads=0x10000
6:     RX queue: 0
7:       RX desc=1024 - RX free threshold=32
8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
9:       RX Offloads=0x0
10:    TX queue: 0
11:      TX desc=1024 - TX free threshold=928
12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
13:      TX offloads=0x10000 - TX RS bit threshold=32

We can see RX/Rx/TX/Tx is mixed used. Also in other places in testpmd,
RX/Rx/TX/Tx is mixed used.

This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change
to unified use Rx/Tx.

Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
V1->V2:
- fix all RX/TX
- rename patch title
---
 app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
 app/test-pmd/config.c      | 128 ++++++++++++++++++++++-----------------------
 app/test-pmd/csumonly.c    |  22 ++++----
 app/test-pmd/icmpecho.c    |   2 +-
 app/test-pmd/ieee1588fwd.c |  18 +++----
 app/test-pmd/parameters.c  |  50 +++++++++---------
 app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
 app/test-pmd/testpmd.h     |  28 +++++-----
 app/test-pmd/txonly.c      |   2 +-
 9 files changed, 237 insertions(+), 237 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index e316f5c..f33fa2f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -182,16 +182,16 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"    Clear information for port_id, or all.\n\n"
 
 			"show (rxq|txq) info (port_id) (queue_id)\n"
-			"    Display information for configured RX/TX queue.\n\n"
+			"    Display information for configured Rx/Tx queue.\n\n"
 
 			"show config (rxtx|cores|fwd|rxoffs|rxpkts|txpkts)\n"
 			"    Display the given configuration.\n\n"
 
 			"read rxd (port_id) (queue_id) (rxd_id)\n"
-			"    Display an RX descriptor of a port RX queue.\n\n"
+			"    Display an Rx descriptor of a port Rx queue.\n\n"
 
 			"read txd (port_id) (queue_id) (txd_id)\n"
-			"    Display a TX descriptor of a port TX queue.\n\n"
+			"    Display a Tx descriptor of a port Tx queue.\n\n"
 
 			"ddp get list (port_id)\n"
 			"    Get ddp profile info list\n\n"
@@ -245,7 +245,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"       Show general information about devices probed.\n\n"
 
 			"show port (port_id) rxq|txq (queue_id) desc (desc_id) status"
-			"       Show status of rx|tx descriptor.\n\n"
+			"       Show status of Rx|Tx descriptor.\n\n"
 
 			"show port (port_id) rxq (queue_id) desc used count\n"
 			"    Show current number of filled receive"
@@ -316,7 +316,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			" and optionally CSUM packets.\n\n"
 
 			"set txsplit (off|on|rand)\n"
-			"    Set the split policy for the TX packets."
+			"    Set the split policy for the Tx packets."
 			" Right now only applicable for CSUM and TXONLY"
 			" modes\n\n"
 
@@ -334,7 +334,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"    Select how attached port is retrieved for setup.\n\n"
 
 			"set tx loopback (port_id) (on|off)\n"
-			"    Enable or disable tx loopback.\n\n"
+			"    Enable or disable Tx loopback.\n\n"
 
 			"set all queues drop (port_id) (on|off)\n"
 			"    Set drop enable bit for all queues.\n\n"
@@ -424,7 +424,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"depends on the number of VLAN IDs) in packets sent on a port.\n\n"
 
 			"tx_vlan set pvid port_id vlan_id (on|off)\n"
-			"    Set port based TX VLAN insertion.\n\n"
+			"    Set port based Tx VLAN insertion.\n\n"
 
 			"tx_vlan reset (port_id)\n"
 			"    Disable hardware insertion of a VLAN header in"
@@ -444,11 +444,11 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"csum parse-tunnel (on|off) (tx_port_id)\n"
 			"    If disabled, treat tunnel packets as non-tunneled"
 			" packets (treat inner headers as payload). The port\n"
-			"    argument is the port used for TX in csum forward"
+			"    argument is the port used for Tx in csum forward"
 			" engine.\n\n"
 
 			"csum show (port_id)\n"
-			"    Display tx checksum offload configuration\n\n"
+			"    Display Tx checksum offload configuration\n\n"
 
 			"tso set (segsize) (portid)\n"
 			"    Enable TCP Segmentation Offload in csum forward"
@@ -536,7 +536,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			" port.\n\n"
 
 			"set stat_qmap (tx|rx) (port_id) (queue_id) (qmapping)\n"
-			"    Set statistics mapping (qmapping 0..15) for RX/TX"
+			"    Set statistics mapping (qmapping 0..15) for Rx/Tx"
 			" queue on port.\n"
 			"    e.g., 'set stat_qmap rx 0 2 5' sets rx queue 2"
 			" on port 0 to mapping 5.\n\n"
@@ -549,7 +549,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"    Set the option to enable measurement of CPU cycles.\n"
 
 			"set record-burst-stats on|off\n"
-			"    Set the option to enable display of RX and TX bursts.\n"
+			"    Set the option to enable display of Rx and Tx bursts.\n"
 
 			"set port (port_id) vf (vf_id) rx|tx on|off\n"
 			"    Enable/Disable a VF receive/tranmit from a port\n\n"
@@ -588,7 +588,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"   Reset a mirror rule.\n\n"
 
 			"set flush_rx (on|off)\n"
-			"   Flush (default) or don't flush RX streams before"
+			"   Flush (default) or don't flush Rx streams before"
 			" forwarding. Mainly used with PCAP drivers.\n\n"
 
 			"set bypass mode (normal|bypass|isolate) (port_id)\n"
@@ -792,7 +792,7 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"    Set the max LRO aggregated packet size.\n\n"
 
 			"port config all drop-en (on|off)\n"
-			"    Enable or disable packet drop on all RX queues of all ports when no "
+			"    Enable or disable packet drop on all Rx queues of all ports when no "
 			"receive buffers available.\n\n"
 
 			"port config all rss (all|default|ip|tcp|udp|sctp|"
@@ -813,29 +813,29 @@ static void cmd_help_long_parsed(void *parsed_result,
 			"port config all (txpt|txht|txwt|rxpt|rxht|rxwt)"
 			" (value)\n"
 			"    Set the ring prefetch/host/writeback threshold"
-			" for tx/rx queue.\n\n"
+			" for Tx/Rx queue.\n\n"
 
 			"port config all (txfreet|txrst|rxfreet) (value)\n"
-			"    Set free threshold for rx/tx, or set"
-			" tx rs bit threshold.\n\n"
+			"    Set free threshold for Rx/Tx, or set"
+			" Tx rs bit threshold.\n\n"
 			"port config mtu X value\n"
 			"    Set the MTU of port X to a given value\n\n"
 
 			"port config (port_id) (rxq|txq) (queue_id) ring_size (value)\n"
-			"    Set a rx/tx queue's ring size configuration, the new"
+			"    Set a Rx/Tx queue's ring size configuration, the new"
 			" value will take effect after command that (re-)start the port"
 			" or command that setup the specific queue\n\n"
 
 			"port (port_id) (rxq|txq) (queue_id) (start|stop)\n"
-			"    Start/stop a rx/tx queue of port X. Only take effect"
+			"    Start/stop a Rx/Tx queue of port X. Only take effect"
 			" when port X is started\n\n"
 
 			"port (port_id) (rxq|txq) (queue_id) deferred_start (on|off)\n"
-			"    Switch on/off a deferred start of port X rx/tx queue. Only"
+			"    Switch on/off a deferred start of port X Rx/Tx queue. Only"
 			" take effect when port X is stopped.\n\n"
 
 			"port (port_id) (rxq|txq) (queue_id) setup\n"
-			"    Setup a rx/tx queue of port X.\n\n"
+			"    Setup a Rx/Tx queue of port X.\n\n"
 
 			"port config (port_id) pctype mapping reset\n"
 			"    Reset flow type to pctype mapping on a port\n\n"
@@ -892,11 +892,11 @@ static void cmd_help_long_parsed(void *parsed_result,
 
 			"bpf-load rx|tx (port) (queue) (J|M|B) (file_name)\n"
 			"    Load an eBPF program as a callback"
-			" for particular RX/TX queue\n\n"
+			" for particular Rx/Tx queue\n\n"
 
 			"bpf-unload rx|tx (port) (queue)\n"
 			"    Unload previously loaded eBPF program"
-			" for particular RX/TX queue\n\n"
+			" for particular Rx/Tx queue\n\n"
 
 			"port config (port_id) tx_metadata (value)\n"
 			"    Set Tx metadata value per port. Testpmd will add this value"
@@ -1807,7 +1807,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
 	}
 	if (!strcmp(res->name, "rxq")) {
 		if (!res->value && !nb_txq) {
-			printf("Warning: Either rx or tx queues should be non zero\n");
+			printf("Warning: Either Rx or Tx queues should be non zero\n");
 			return;
 		}
 		if (check_nb_rxq(res->value) != 0)
@@ -1816,7 +1816,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
 	}
 	else if (!strcmp(res->name, "txq")) {
 		if (!res->value && !nb_rxq) {
-			printf("Warning: Either rx or tx queues should be non zero\n");
+			printf("Warning: Either Rx or Tx queues should be non zero\n");
 			return;
 		}
 		if (check_nb_txq(res->value) != 0)
@@ -2082,7 +2082,7 @@ cmdline_parse_inst_t cmd_config_mtu = {
 	},
 };
 
-/* *** configure rx mode *** */
+/* *** configure Rx mode *** */
 struct cmd_config_rx_mode_flag {
 	cmdline_fixed_string_t port;
 	cmdline_fixed_string_t keyword;
@@ -2496,7 +2496,7 @@ cmd_config_rxtx_ring_size_parsed(void *parsed_result,
 		return;
 
 	if (isrx && res->size != 0 && res->size <= rx_free_thresh) {
-		printf("Invalid rx ring_size, must > rx_free_thresh: %d\n",
+		printf("Invalid Rx ring_size, must > rx_free_thresh: %d\n",
 		       rx_free_thresh);
 		return;
 	}
@@ -2779,10 +2779,10 @@ cmd_setup_rxtx_queue_parsed(
 	}
 
 	if (isrx && rx_queue_id_is_invalid(res->qid)) {
-		printf("Invalid rx queue\n");
+		printf("Invalid Rx queue\n");
 		return;
 	} else if (!isrx && tx_queue_id_is_invalid(res->qid)) {
-		printf("Invalid tx queue\n");
+		printf("Invalid Tx queue\n");
 		return;
 	}
 
@@ -2794,7 +2794,7 @@ cmd_setup_rxtx_queue_parsed(
 
 		mp = mbuf_pool_find(socket_id, 0);
 		if (mp == NULL) {
-			printf("Failed to setup RX queue: "
+			printf("Failed to setup Rx queue: "
 				"No mempool allocation"
 				" on the socket %d\n",
 				rxring_numa[res->portid]);
@@ -2807,7 +2807,7 @@ cmd_setup_rxtx_queue_parsed(
 				     &port->rx_conf[res->qid],
 				     mp);
 		if (ret)
-			printf("Failed to setup RX queue\n");
+			printf("Failed to setup Rx queue\n");
 	} else {
 		socket_id = txring_numa[res->portid];
 		if (!numa_support || socket_id == NUMA_NO_CONFIG)
@@ -2819,7 +2819,7 @@ cmd_setup_rxtx_queue_parsed(
 					     socket_id,
 					     &port->tx_conf[res->qid]);
 		if (ret)
-			printf("Failed to setup TX queue\n");
+			printf("Failed to setup Tx queue\n");
 	}
 }
 
@@ -3343,7 +3343,7 @@ cmdline_parse_inst_t cmd_config_burst = {
 	},
 };
 
-/* *** configure rx/tx queues *** */
+/* *** configure Rx/Tx queues *** */
 struct cmd_config_thresh {
 	cmdline_fixed_string_t port;
 	cmdline_fixed_string_t keyword;
@@ -4144,7 +4144,7 @@ cmdline_parse_inst_t cmd_vlan_offload = {
 	.data = NULL,
 	.help_str = "vlan set strip|filter|qinq_strip|extend|stripq on|off "
 		"<port_id[,queue_id]>: "
-		"Strip/Filter/QinQ for rx side Extend for both rx/tx sides",
+		"Strip/Filter/QinQ for Rx side Extend for both Rx/Tx sides",
 	.tokens = {
 		(void *)&cmd_vlan_offload_vlan,
 		(void *)&cmd_vlan_offload_set,
@@ -4568,7 +4568,7 @@ cmd_config_queue_tx_offloads(struct rte_port *port)
 {
 	int k;
 
-	/* Apply queue tx offloads configuration */
+	/* Apply queue Tx offloads configuration */
 	for (k = 0; k < port->dev_info.max_rx_queues; k++)
 		port->tx_conf[k].offloads =
 			port->dev_conf.txmode.offloads;
@@ -5369,7 +5369,7 @@ cmdline_parse_token_string_t cmd_setflushrx_mode =
 
 cmdline_parse_inst_t cmd_set_flush_rx = {
 	.f = cmd_set_flush_rx_parsed,
-	.help_str = "set flush_rx on|off: Enable/Disable flush on rx streams",
+	.help_str = "set flush_rx on|off: Enable/Disable flush on Rx streams",
 	.data = NULL,
 	.tokens = {
 		(void *)&cmd_setflushrx_set,
@@ -6978,7 +6978,7 @@ cmdline_parse_inst_t cmd_link_flow_control_set_rx = {
 	.f = cmd_link_flow_ctrl_set_parsed,
 	.data = (void *)&cmd_link_flow_control_set_rx,
 	.help_str = "set flow_ctrl rx on|off <port_id>: "
-		"Change rx flow control parameter",
+		"Change Rx flow control parameter",
 	.tokens = {
 		(void *)&cmd_lfc_set_set,
 		(void *)&cmd_lfc_set_flow_ctrl,
@@ -6993,7 +6993,7 @@ cmdline_parse_inst_t cmd_link_flow_control_set_tx = {
 	.f = cmd_link_flow_ctrl_set_parsed,
 	.data = (void *)&cmd_link_flow_control_set_tx,
 	.help_str = "set flow_ctrl tx on|off <port_id>: "
-		"Change tx flow control parameter",
+		"Change Tx flow control parameter",
 	.tokens = {
 		(void *)&cmd_lfc_set_set,
 		(void *)&cmd_lfc_set_flow_ctrl,
@@ -7107,9 +7107,9 @@ cmd_link_flow_ctrl_set_parsed(void *parsed_result,
 	int ret;
 
 	/*
-	 * Rx on/off, flow control is enabled/disabled on RX side. This can indicate
+	 * Rx on/off, flow control is enabled/disabled on Rx side. This can indicate
 	 * the RTE_FC_TX_PAUSE, Transmit pause frame at the Rx side.
-	 * Tx on/off, flow control is enabled/disabled on TX side. This can indicate
+	 * Tx on/off, flow control is enabled/disabled on Tx side. This can indicate
 	 * the RTE_FC_RX_PAUSE, Respond to the pause frame at the Tx side.
 	 */
 	static enum rte_eth_fc_mode rx_tx_onoff_2_lfc_mode[2][2] = {
@@ -7194,9 +7194,9 @@ cmd_priority_flow_ctrl_set_parsed(void *parsed_result,
 	int ret;
 
 	/*
-	 * Rx on/off, flow control is enabled/disabled on RX side. This can indicate
+	 * Rx on/off, flow control is enabled/disabled on Rx side. This can indicate
 	 * the RTE_FC_TX_PAUSE, Transmit pause frame at the Rx side.
-	 * Tx on/off, flow control is enabled/disabled on TX side. This can indicate
+	 * Tx on/off, flow control is enabled/disabled on Tx side. This can indicate
 	 * the RTE_FC_RX_PAUSE, Respond to the pause frame at the Tx side.
 	 */
 	static enum rte_eth_fc_mode rx_tx_onoff_2_pfc_mode[2][2] = {
@@ -8366,7 +8366,7 @@ cmdline_parse_inst_t cmd_set_qmap = {
 	.f = cmd_set_qmap_parsed,
 	.data = NULL,
 	.help_str = "set stat_qmap rx|tx <port_id> <queue_id> <map_value>: "
-		"Set statistics mapping value on tx|rx queue_id of port_id",
+		"Set statistics mapping value on Tx|Rx queue_id of port_id",
 	.tokens = {
 		(void *)&cmd_setqmap_set,
 		(void *)&cmd_setqmap_qmap,
@@ -11109,9 +11109,9 @@ cmdline_parse_inst_t cmd_set_vf_vlan_insert = {
 	},
 };
 
-/* tx loopback configuration */
+/* Tx loopback configuration */
 
-/* Common result structure for tx loopback */
+/* Common result structure for Tx loopback */
 struct cmd_tx_loopback_result {
 	cmdline_fixed_string_t set;
 	cmdline_fixed_string_t tx;
@@ -11120,7 +11120,7 @@ struct cmd_tx_loopback_result {
 	cmdline_fixed_string_t on_off;
 };
 
-/* Common CLI fields for tx loopback enable disable */
+/* Common CLI fields for Tx loopback enable disable */
 cmdline_parse_token_string_t cmd_tx_loopback_set =
 	TOKEN_STRING_INITIALIZER
 		(struct cmd_tx_loopback_result,
@@ -11216,7 +11216,7 @@ struct cmd_all_queues_drop_en_result {
 	cmdline_fixed_string_t on_off;
 };
 
-/* Common CLI fields for tx loopback enable disable */
+/* Common CLI fields for Tx loopback enable disable */
 cmdline_parse_token_string_t cmd_all_queues_drop_en_set =
 	TOKEN_STRING_INITIALIZER
 		(struct cmd_all_queues_drop_en_result,
@@ -12281,7 +12281,7 @@ cmdline_parse_inst_t cmd_set_vf_vlan_tag = {
 	},
 };
 
-/* Common definition of VF and TC TX bandwidth configuration */
+/* Common definition of VF and TC Tx bandwidth configuration */
 struct cmd_vf_tc_bw_result {
 	cmdline_fixed_string_t set;
 	cmdline_fixed_string_t vf;
@@ -14439,13 +14439,13 @@ cmd_show_vf_stats_parsed(
 	printf("\n  %s NIC statistics for port %-2d vf %-2d %s\n",
 		nic_stats_border, res->port_id, res->vf_id, nic_stats_border);
 
-	printf("  RX-packets: %-10"PRIu64" RX-missed: %-10"PRIu64" RX-bytes:  "
+	printf("  Rx-packets: %-10"PRIu64" Rx-missed: %-10"PRIu64" Rx-bytes:  "
 	       "%-"PRIu64"\n",
 	       stats.ipackets, stats.imissed, stats.ibytes);
-	printf("  RX-errors: %-"PRIu64"\n", stats.ierrors);
-	printf("  RX-nombuf:  %-10"PRIu64"\n",
+	printf("  Rx-errors: %-"PRIu64"\n", stats.ierrors);
+	printf("  Rx-nombuf:  %-10"PRIu64"\n",
 	       stats.rx_nombuf);
-	printf("  TX-packets: %-10"PRIu64" TX-errors: %-10"PRIu64" TX-bytes:  "
+	printf("  Tx-packets: %-10"PRIu64" Tx-errors: %-10"PRIu64" Tx-bytes:  "
 	       "%-"PRIu64"\n",
 	       stats.opackets, stats.oerrors, stats.obytes);
 
@@ -16602,7 +16602,7 @@ cmdline_parse_inst_t cmd_show_port_supported_ptypes = {
 	},
 };
 
-/* *** display rx/tx descriptor status *** */
+/* *** display Rx/Tx descriptor status *** */
 struct cmd_show_rx_tx_desc_status_result {
 	cmdline_fixed_string_t cmd_show;
 	cmdline_fixed_string_t cmd_port;
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index c89f8cd..bc5c989 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -194,11 +194,11 @@ nic_stats_display(portid_t port_id)
 	printf("\n  %s NIC statistics for port %-2d %s\n",
 	       nic_stats_border, port_id, nic_stats_border);
 
-	printf("  RX-packets: %-10"PRIu64" RX-missed: %-10"PRIu64" RX-bytes:  "
+	printf("  Rx-packets: %-10"PRIu64" Rx-missed: %-10"PRIu64" Rx-bytes:  "
 	       "%-"PRIu64"\n", stats.ipackets, stats.imissed, stats.ibytes);
-	printf("  RX-errors: %-"PRIu64"\n", stats.ierrors);
-	printf("  RX-nombuf:  %-10"PRIu64"\n", stats.rx_nombuf);
-	printf("  TX-packets: %-10"PRIu64" TX-errors: %-10"PRIu64" TX-bytes:  "
+	printf("  Rx-errors: %-"PRIu64"\n", stats.ierrors);
+	printf("  Rx-nombuf:  %-10"PRIu64"\n", stats.rx_nombuf);
+	printf("  Tx-packets: %-10"PRIu64" Tx-errors: %-10"PRIu64" Tx-bytes:  "
 	       "%-"PRIu64"\n", stats.opackets, stats.oerrors, stats.obytes);
 
 	diff_ns = 0;
@@ -373,27 +373,27 @@ rx_queue_infos_display(portid_t port_id, uint16_t queue_id)
 	rc = rte_eth_rx_queue_info_get(port_id, queue_id, &qinfo);
 	if (rc != 0) {
 		printf("Failed to retrieve information for port: %u, "
-			"RX queue: %hu\nerror desc: %s(%d)\n",
+			"Rx queue: %hu\nerror desc: %s(%d)\n",
 			port_id, queue_id, strerror(-rc), rc);
 		return;
 	}
 
-	printf("\n%s Infos for port %-2u, RX queue %-2u %s",
+	printf("\n%s Infos for port %-2u, Rx queue %-2u %s",
 	       info_border, port_id, queue_id, info_border);
 
 	printf("\nMempool: %s", (qinfo.mp == NULL) ? "NULL" : qinfo.mp->name);
-	printf("\nRX prefetch threshold: %hhu", qinfo.conf.rx_thresh.pthresh);
-	printf("\nRX host threshold: %hhu", qinfo.conf.rx_thresh.hthresh);
-	printf("\nRX writeback threshold: %hhu", qinfo.conf.rx_thresh.wthresh);
-	printf("\nRX free threshold: %hu", qinfo.conf.rx_free_thresh);
-	printf("\nRX drop packets: %s",
+	printf("\nRx prefetch threshold: %hhu", qinfo.conf.rx_thresh.pthresh);
+	printf("\nRx host threshold: %hhu", qinfo.conf.rx_thresh.hthresh);
+	printf("\nRx writeback threshold: %hhu", qinfo.conf.rx_thresh.wthresh);
+	printf("\nRx free threshold: %hu", qinfo.conf.rx_free_thresh);
+	printf("\nRx drop packets: %s",
 		(qinfo.conf.rx_drop_en != 0) ? "on" : "off");
-	printf("\nRX deferred start: %s",
+	printf("\nRx deferred start: %s",
 		(qinfo.conf.rx_deferred_start != 0) ? "on" : "off");
-	printf("\nRX scattered packets: %s",
+	printf("\nRx scattered packets: %s",
 		(qinfo.scattered_rx != 0) ? "on" : "off");
 	if (qinfo.rx_buf_size != 0)
-		printf("\nRX buffer size: %hu", qinfo.rx_buf_size);
+		printf("\nRx buffer size: %hu", qinfo.rx_buf_size);
 	printf("\nNumber of RXDs: %hu", qinfo.nb_desc);
 
 	if (rte_eth_rx_burst_mode_get(port_id, queue_id, &mode) == 0)
@@ -416,20 +416,20 @@ tx_queue_infos_display(portid_t port_id, uint16_t queue_id)
 	rc = rte_eth_tx_queue_info_get(port_id, queue_id, &qinfo);
 	if (rc != 0) {
 		printf("Failed to retrieve information for port: %u, "
-			"TX queue: %hu\nerror desc: %s(%d)\n",
+			"Tx queue: %hu\nerror desc: %s(%d)\n",
 			port_id, queue_id, strerror(-rc), rc);
 		return;
 	}
 
-	printf("\n%s Infos for port %-2u, TX queue %-2u %s",
+	printf("\n%s Infos for port %-2u, Tx queue %-2u %s",
 	       info_border, port_id, queue_id, info_border);
 
-	printf("\nTX prefetch threshold: %hhu", qinfo.conf.tx_thresh.pthresh);
-	printf("\nTX host threshold: %hhu", qinfo.conf.tx_thresh.hthresh);
-	printf("\nTX writeback threshold: %hhu", qinfo.conf.tx_thresh.wthresh);
-	printf("\nTX RS threshold: %hu", qinfo.conf.tx_rs_thresh);
-	printf("\nTX free threshold: %hu", qinfo.conf.tx_free_thresh);
-	printf("\nTX deferred start: %s",
+	printf("\nTx prefetch threshold: %hhu", qinfo.conf.tx_thresh.pthresh);
+	printf("\nTx host threshold: %hhu", qinfo.conf.tx_thresh.hthresh);
+	printf("\nTx writeback threshold: %hhu", qinfo.conf.tx_thresh.wthresh);
+	printf("\nTx RS threshold: %hu", qinfo.conf.tx_rs_thresh);
+	printf("\nTx free threshold: %hu", qinfo.conf.tx_free_thresh);
+	printf("\nTx deferred start: %s",
 		(qinfo.conf.tx_deferred_start != 0) ? "on" : "off");
 	printf("\nNumber of TXDs: %hu", qinfo.nb_desc);
 
@@ -678,8 +678,8 @@ port_infos_display(portid_t port_id)
 		}
 	}
 
-	printf("Minimum size of RX buffer: %u\n", dev_info.min_rx_bufsize);
-	printf("Maximum configurable length of RX packet: %u\n",
+	printf("Minimum size of Rx buffer: %u\n", dev_info.min_rx_bufsize);
+	printf("Maximum configurable length of Rx packet: %u\n",
 		dev_info.max_rx_pktlen);
 	printf("Maximum configurable size of LRO aggregated packet: %u\n",
 		dev_info.max_lro_pkt_size);
@@ -689,16 +689,16 @@ port_infos_display(portid_t port_id)
 		printf("Maximum number of VMDq pools: %u\n",
 			dev_info.max_vmdq_pools);
 
-	printf("Current number of RX queues: %u\n", dev_info.nb_rx_queues);
-	printf("Max possible RX queues: %u\n", dev_info.max_rx_queues);
+	printf("Current number of Rx queues: %u\n", dev_info.nb_rx_queues);
+	printf("Max possible Rx queues: %u\n", dev_info.max_rx_queues);
 	printf("Max possible number of RXDs per queue: %hu\n",
 		dev_info.rx_desc_lim.nb_max);
 	printf("Min possible number of RXDs per queue: %hu\n",
 		dev_info.rx_desc_lim.nb_min);
 	printf("RXDs number alignment: %hu\n", dev_info.rx_desc_lim.nb_align);
 
-	printf("Current number of TX queues: %u\n", dev_info.nb_tx_queues);
-	printf("Max possible TX queues: %u\n", dev_info.max_tx_queues);
+	printf("Current number of Tx queues: %u\n", dev_info.nb_tx_queues);
+	printf("Max possible Tx queues: %u\n", dev_info.max_tx_queues);
 	printf("Max possible number of TXDs per queue: %hu\n",
 		dev_info.tx_desc_lim.nb_max);
 	printf("Min possible number of TXDs per queue: %hu\n",
@@ -2200,14 +2200,14 @@ port_flow_isolate(portid_t port_id, int set)
 }
 
 /*
- * RX/TX ring descriptors display functions.
+ * Rx/Tx ring descriptors display functions.
  */
 int
 rx_queue_id_is_invalid(queueid_t rxq_id)
 {
 	if (rxq_id < nb_rxq)
 		return 0;
-	printf("Invalid RX queue %d (must be < nb_rxq=%d)\n", rxq_id, nb_rxq);
+	printf("Invalid Rx queue %d (must be < nb_rxq=%d)\n", rxq_id, nb_rxq);
 	return 1;
 }
 
@@ -2216,7 +2216,7 @@ tx_queue_id_is_invalid(queueid_t txq_id)
 {
 	if (txq_id < nb_txq)
 		return 0;
-	printf("Invalid TX queue %d (must be < nb_txq=%d)\n", txq_id, nb_txq);
+	printf("Invalid Tx queue %d (must be < nb_txq=%d)\n", txq_id, nb_txq);
 	return 1;
 }
 
@@ -2297,7 +2297,7 @@ rx_desc_id_is_invalid(portid_t port_id, queueid_t rxq_id, uint16_t rxdesc_id)
 	if (rxdesc_id < ring_size)
 		return 0;
 
-	printf("Invalid RX descriptor %u (must be < ring_size=%u)\n",
+	printf("Invalid Rx descriptor %u (must be < ring_size=%u)\n",
 	       rxdesc_id, ring_size);
 	return 1;
 }
@@ -2315,7 +2315,7 @@ tx_desc_id_is_invalid(portid_t port_id, queueid_t txq_id, uint16_t txdesc_id)
 	if (txdesc_id < ring_size)
 		return 0;
 
-	printf("Invalid TX descriptor %u (must be < ring_size=%u)\n",
+	printf("Invalid Tx descriptor %u (must be < ring_size=%u)\n",
 	       txdesc_id, ring_size);
 	return 1;
 }
@@ -2388,7 +2388,7 @@ ring_rx_descriptor_display(const struct rte_memzone *ring_mz,
 		return;
 
 	if (strstr(dev_info.driver_name, "i40e") != NULL) {
-		/* 32 bytes RX descriptor, i40e only */
+		/* 32 bytes Rx descriptor, i40e only */
 		struct igb_ring_desc_32_bytes *ring =
 			(struct igb_ring_desc_32_bytes *)ring_mz->addr;
 		ring[desc_id].lo_dword.dword =
@@ -2407,7 +2407,7 @@ ring_rx_descriptor_display(const struct rte_memzone *ring_mz,
 		return;
 	}
 #endif
-	/* 16 bytes RX descriptor */
+	/* 16 bytes Rx descriptor */
 	ring[desc_id].lo_dword.dword =
 		rte_le_to_cpu_64(ring[desc_id].lo_dword.dword);
 	ring_rxd_display_dword(ring[desc_id].lo_dword);
@@ -2505,14 +2505,14 @@ rxtx_config_display(void)
 		int32_t rc;
 
 		/* per port config */
-		printf("  port %d: RX queue number: %d Tx queue number: %d\n",
+		printf("  port %d: Rx queue number: %d Tx queue number: %d\n",
 				(unsigned int)pid, nb_rxq, nb_txq);
 
 		printf("    Rx offloads=0x%"PRIx64" Tx offloads=0x%"PRIx64"\n",
 				ports[pid].dev_conf.rxmode.offloads,
 				ports[pid].dev_conf.txmode.offloads);
 
-		/* per rx queue config only for first queue to be less verbose */
+		/* per Rx queue config only for first queue to be less verbose */
 		for (qid = 0; qid < 1; qid++) {
 			rc = rte_eth_rx_queue_info_get(pid, qid, &rx_qinfo);
 			if (rc) {
@@ -2533,16 +2533,16 @@ rxtx_config_display(void)
 				offloads_tmp = rx_qinfo.conf.offloads;
 			}
 
-			printf("    RX queue: %d\n", qid);
-			printf("      RX desc=%d - RX free threshold=%d\n",
+			printf("    Rx queue: %d\n", qid);
+			printf("      Rx desc=%d - Rx free threshold=%d\n",
 				nb_rx_desc_tmp, rx_free_thresh_tmp);
-			printf("      RX threshold registers: pthresh=%d hthresh=%d "
+			printf("      Rx threshold registers: pthresh=%d hthresh=%d "
 				" wthresh=%d\n",
 				pthresh_tmp, hthresh_tmp, wthresh_tmp);
-			printf("      RX Offloads=0x%"PRIx64"\n", offloads_tmp);
+			printf("      Rx Offloads=0x%"PRIx64"\n", offloads_tmp);
 		}
 
-		/* per tx queue config only for first queue to be less verbose */
+		/* per Tx queue config only for first queue to be less verbose */
 		for (qid = 0; qid < 1; qid++) {
 			rc = rte_eth_tx_queue_info_get(pid, qid, &tx_qinfo);
 			if (rc) {
@@ -2565,13 +2565,13 @@ rxtx_config_display(void)
 				tx_rs_thresh_tmp = tx_qinfo.conf.tx_rs_thresh;
 			}
 
-			printf("    TX queue: %d\n", qid);
-			printf("      TX desc=%d - TX free threshold=%d\n",
+			printf("    Tx queue: %d\n", qid);
+			printf("      Tx desc=%d - Tx free threshold=%d\n",
 				nb_tx_desc_tmp, tx_free_thresh_tmp);
-			printf("      TX threshold registers: pthresh=%d hthresh=%d "
+			printf("      Tx threshold registers: pthresh=%d hthresh=%d "
 				" wthresh=%d\n",
 				pthresh_tmp, hthresh_tmp, wthresh_tmp);
-			printf("      TX offloads=0x%"PRIx64" - TX RS bit threshold=%d\n",
+			printf("      Tx offloads=0x%"PRIx64" - Tx RS bit threshold=%d\n",
 				offloads_tmp, tx_rs_thresh_tmp);
 		}
 	}
@@ -2816,8 +2816,8 @@ simple_fwd_config_setup(void)
 
 /**
  * For the RSS forwarding test all streams distributed over lcores. Each stream
- * being composed of a RX queue to poll on a RX port for input messages,
- * associated with a TX queue of a TX port where to send forwarded packets.
+ * being composed of a Rx queue to poll on a Rx port for input messages,
+ * associated with a Tx queue of a Tx port where to send forwarded packets.
  */
 static void
 rss_fwd_config_setup(void)
@@ -2883,9 +2883,9 @@ get_fwd_port_total_tc_num(void)
  * For the DCB forwarding test, each core is assigned on each traffic class.
  *
  * Each core is assigned a multi-stream, each stream being composed of
- * a RX queue to poll on a RX port for input messages, associated with
- * a TX queue of a TX port where to send forwarded packets. All RX and
- * TX queues are mapping to the same traffic class.
+ * a Rx queue to poll on a Rx port for input messages, associated with
+ * a Tx queue of a Tx port where to send forwarded packets. All Rx and
+ * Tx queues are mapping to the same traffic class.
  * If VMDQ and DCB co-exist, each traffic class on different POOLs share
  * the same core
  */
@@ -2913,7 +2913,7 @@ dcb_fwd_config_setup(void)
 	init_fwd_streams();
 	sm_id = 0;
 	txp = 1;
-	/* get the dcb info on the first RX and TX ports */
+	/* get the dcb info on the first Rx and Tx ports */
 	(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[rxp], &rxp_dcb_info);
 	(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[txp], &txp_dcb_info);
 
@@ -2951,7 +2951,7 @@ dcb_fwd_config_setup(void)
 		tc++;
 		if (tc < rxp_dcb_info.nb_tcs)
 			continue;
-		/* Restart from TC 0 on next RX port */
+		/* Restart from TC 0 on next Rx port */
 		tc = 0;
 		if (numa_support && (nb_fwd_ports <= (nb_ports >> 1)))
 			rxp = (portid_t)
@@ -2960,7 +2960,7 @@ dcb_fwd_config_setup(void)
 			rxp++;
 		if (rxp >= nb_fwd_ports)
 			return;
-		/* get the dcb information on next RX and TX ports */
+		/* get the dcb information on next Rx and Tx ports */
 		if ((rxp & 0x1) == 0)
 			txp = (portid_t) (rxp + 1);
 		else
@@ -3080,7 +3080,7 @@ pkt_fwd_config_display(struct fwd_config *cfg)
 		mp_alloc_to_str(mp_alloc_type));
 
 	if (retry_enabled)
-		printf("TX retry num: %u, delay between TX retries: %uus\n",
+		printf("Tx retry num: %u, delay between Tx retries: %uus\n",
 			burst_tx_retry_num, burst_tx_delay_time);
 	for (lc_id = 0; lc_id < cfg->nb_fwd_lcores; lc_id++) {
 		printf("Logical Core %u (socket %u) forwards packets on "
@@ -3090,7 +3090,7 @@ pkt_fwd_config_display(struct fwd_config *cfg)
 		       fwd_lcores[lc_id]->stream_nb);
 		for (sm_id = 0; sm_id < fwd_lcores[lc_id]->stream_nb; sm_id++) {
 			fs = fwd_streams[fwd_lcores[lc_id]->stream_idx + sm_id];
-			printf("\n  RX P=%d/Q=%d (socket %u) -> TX "
+			printf("\n  Rx P=%d/Q=%d (socket %u) -> Tx "
 			       "P=%d/Q=%d (socket %u) ",
 			       fs->rx_port, fs->rx_queue,
 			       ports[fs->rx_port].socket_id,
@@ -3477,7 +3477,7 @@ set_rx_pkt_offsets(unsigned int *seg_offsets, unsigned int nb_offs)
 	unsigned int i;
 
 	if (nb_offs >= MAX_SEGS_BUFFER_SPLIT) {
-		printf("nb segments per RX packets=%u >= "
+		printf("nb segments per Rx packets=%u >= "
 		       "MAX_SEGS_BUFFER_SPLIT - ignored\n", nb_offs);
 		return;
 	}
@@ -3521,7 +3521,7 @@ set_rx_pkt_segments(unsigned int *seg_lengths, unsigned int nb_segs)
 	unsigned int i;
 
 	if (nb_segs >= MAX_SEGS_BUFFER_SPLIT) {
-		printf("nb segments per RX packets=%u >= "
+		printf("nb segments per Rx packets=%u >= "
 		       "MAX_SEGS_BUFFER_SPLIT - ignored\n", nb_segs);
 		return;
 	}
@@ -3577,8 +3577,8 @@ nb_segs_is_invalid(unsigned int nb_segs)
 				return true;
 
 			if (ring_size < nb_segs) {
-				printf("nb segments per TX packets=%u >= "
-				       "TX queue(%u) ring_size=%u - ignored\n",
+				printf("nb segments per Tx packets=%u >= "
+				       "Tx queue(%u) ring_size=%u - ignored\n",
 				       nb_segs, queue_id, ring_size);
 				return true;
 			}
@@ -4204,18 +4204,18 @@ set_qmap(portid_t port_id, uint8_t is_rx, uint16_t queue_id, uint8_t map_value)
 		return;
 	}
 
-	if (!is_rx) { /* tx */
+	if (!is_rx) { /* Tx */
 		ret = rte_eth_dev_set_tx_queue_stats_mapping(port_id, queue_id,
 							     map_value);
 		if (ret) {
-			printf("failed to set tx queue stats mapping.\n");
+			printf("failed to set Tx queue stats mapping.\n");
 			return;
 		}
-	} else { /* rx */
+	} else { /* Rx */
 		ret = rte_eth_dev_set_rx_queue_stats_mapping(port_id, queue_id,
 							     map_value);
 		if (ret) {
-			printf("failed to set rx queue stats mapping.\n");
+			printf("failed to set Rx queue stats mapping.\n");
 			return;
 		}
 	}
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 6b4df33..eadfcd9 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -258,7 +258,7 @@ parse_vxlan(struct rte_udp_hdr *udp_hdr,
 	struct rte_ether_hdr *eth_hdr;
 
 	/* check udp destination port, RTE_VXLAN_DEFAULT_PORT (4789) is the
-	 * default vxlan port (rfc7348) or that the rx offload flag is set
+	 * default vxlan port (rfc7348) or that the Rx offload flag is set
 	 * (i40e only currently)
 	 */
 	if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) &&
@@ -1008,26 +1008,26 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 			printf("-----------------\n");
 			printf("port=%u, mbuf=%p, pkt_len=%u, nb_segs=%u:\n",
 				fs->rx_port, m, m->pkt_len, m->nb_segs);
-			/* dump rx parsed packet info */
+			/* dump Rx parsed packet info */
 			rte_get_rx_ol_flag_list(rx_ol_flags, buf, sizeof(buf));
-			printf("rx: l2_len=%d ethertype=%x l3_len=%d "
+			printf("Rx: l2_len=%d ethertype=%x l3_len=%d "
 				"l4_proto=%d l4_len=%d flags=%s\n",
 				info.l2_len, rte_be_to_cpu_16(info.ethertype),
 				info.l3_len, info.l4_proto, info.l4_len, buf);
 			if (rx_ol_flags & PKT_RX_LRO)
-				printf("rx: m->lro_segsz=%u\n", m->tso_segsz);
+				printf("Rx: m->lro_segsz=%u\n", m->tso_segsz);
 			if (info.is_tunnel == 1)
-				printf("rx: outer_l2_len=%d outer_ethertype=%x "
+				printf("Rx: outer_l2_len=%d outer_ethertype=%x "
 					"outer_l3_len=%d\n", info.outer_l2_len,
 					rte_be_to_cpu_16(info.outer_ethertype),
 					info.outer_l3_len);
-			/* dump tx packet info */
+			/* dump Tx packet info */
 			if ((tx_offloads & (DEV_TX_OFFLOAD_IPV4_CKSUM |
 					    DEV_TX_OFFLOAD_UDP_CKSUM |
 					    DEV_TX_OFFLOAD_TCP_CKSUM |
 					    DEV_TX_OFFLOAD_SCTP_CKSUM)) ||
 				info.tso_segsz != 0)
-				printf("tx: m->l2_len=%d m->l3_len=%d "
+				printf("Tx: m->l2_len=%d m->l3_len=%d "
 					"m->l4_len=%d\n",
 					m->l2_len, m->l3_len, m->l4_len);
 			if (info.is_tunnel == 1) {
@@ -1036,19 +1036,19 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
 				    (tx_offloads &
 				    DEV_TX_OFFLOAD_OUTER_UDP_CKSUM) ||
 				    (tx_ol_flags & PKT_TX_OUTER_IPV6))
-					printf("tx: m->outer_l2_len=%d "
+					printf("Tx: m->outer_l2_len=%d "
 						"m->outer_l3_len=%d\n",
 						m->outer_l2_len,
 						m->outer_l3_len);
 				if (info.tunnel_tso_segsz != 0 &&
 						(m->ol_flags & PKT_TX_TCP_SEG))
-					printf("tx: m->tso_segsz=%d\n",
+					printf("Tx: m->tso_segsz=%d\n",
 						m->tso_segsz);
 			} else if (info.tso_segsz != 0 &&
 					(m->ol_flags & PKT_TX_TCP_SEG))
-				printf("tx: m->tso_segsz=%d\n", m->tso_segsz);
+				printf("Tx: m->tso_segsz=%d\n", m->tso_segsz);
 			rte_get_tx_ol_flag_list(m->ol_flags, buf, sizeof(buf));
-			printf("tx: flags=%s", buf);
+			printf("Tx: flags=%s", buf);
 			printf("\n");
 		}
 	}
diff --git a/app/test-pmd/icmpecho.c b/app/test-pmd/icmpecho.c
index af6f7e7..ddcb0b5 100644
--- a/app/test-pmd/icmpecho.c
+++ b/app/test-pmd/icmpecho.c
@@ -386,7 +386,7 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
 
 			/* Use source MAC address as destination MAC address. */
 			rte_ether_addr_copy(&eth_h->s_addr, &eth_h->d_addr);
-			/* Set source MAC address with MAC address of TX port */
+			/* Set source MAC address with MAC address of Tx port */
 			rte_ether_addr_copy(&ports[fs->tx_port].eth_addr,
 					&eth_h->s_addr);
 
diff --git a/app/test-pmd/ieee1588fwd.c b/app/test-pmd/ieee1588fwd.c
index e3b98e3..2fe5a5b 100644
--- a/app/test-pmd/ieee1588fwd.c
+++ b/app/test-pmd/ieee1588fwd.c
@@ -42,12 +42,12 @@ struct ptpv2_msg {
  * Check that each received packet is a IEEE1588 PTP V2 packet of type
  * PTP_SYNC_MESSAGE, and that it has been identified and timestamped
  * by the hardware.
- * Check that the value of the last RX timestamp recorded by the controller
+ * Check that the value of the last Rx timestamp recorded by the controller
  * is greater than the previous one.
  *
  * If everything is OK, send the received packet back on the same port,
  * requesting for it to be timestamped by the hardware.
- * Check that the value of the last TX timestamp recorded by the controller
+ * Check that the value of the last Tx timestamp recorded by the controller
  * is greater than the previous one.
  */
 
@@ -57,10 +57,10 @@ port_ieee1588_rx_timestamp_check(portid_t pi, uint32_t index)
 	struct timespec timestamp = {0, 0};
 
 	if (rte_eth_timesync_read_rx_timestamp(pi, &timestamp, index) < 0) {
-		printf("Port %u RX timestamp registers not valid\n", pi);
+		printf("Port %u Rx timestamp registers not valid\n", pi);
 		return;
 	}
-	printf("Port %u RX timestamp value %lu s %lu ns\n",
+	printf("Port %u Rx timestamp value %lu s %lu ns\n",
 		pi, timestamp.tv_sec, timestamp.tv_nsec);
 }
 
@@ -78,12 +78,12 @@ port_ieee1588_tx_timestamp_check(portid_t pi)
 		wait_us++;
 	}
 	if (wait_us >= MAX_TX_TMST_WAIT_MICROSECS) {
-		printf("Port %u TX timestamp registers not valid after "
+		printf("Port %u Tx timestamp registers not valid after "
 		       "%u micro-seconds\n",
 		       pi, MAX_TX_TMST_WAIT_MICROSECS);
 		return;
 	}
-	printf("Port %u TX timestamp value %lu s %lu ns validated after "
+	printf("Port %u Tx timestamp value %lu s %lu ns validated after "
 	       "%u micro-second%s\n",
 	       pi, timestamp.tv_sec, timestamp.tv_nsec, wait_us,
 	       (wait_us == 1) ? "" : "s");
@@ -174,7 +174,7 @@ ieee1588_packet_fwd(struct fwd_stream *fs)
 	/* For i40e we need the timesync register index. It is ignored for the
 	 * other PMDs. */
 	timesync_index = mb->timesync & 0x3;
-	/* Read and check the RX timestamp. */
+	/* Read and check the Rx timestamp. */
 	port_ieee1588_rx_timestamp_check(fs->rx_port, timesync_index);
 
 	/* Swap dest and src mac addresses. */
@@ -182,7 +182,7 @@ ieee1588_packet_fwd(struct fwd_stream *fs)
 	rte_ether_addr_copy(&eth_hdr->s_addr, &eth_hdr->d_addr);
 	rte_ether_addr_copy(&addr, &eth_hdr->s_addr);
 
-	/* Forward PTP packet with hardware TX timestamp */
+	/* Forward PTP packet with hardware Tx timestamp */
 	mb->ol_flags |= PKT_TX_IEEE1588_TMST;
 	fs->tx_packets += 1;
 	if (rte_eth_tx_burst(fs->rx_port, fs->tx_queue, &mb, 1) == 0) {
@@ -193,7 +193,7 @@ ieee1588_packet_fwd(struct fwd_stream *fs)
 	}
 
 	/*
-	 * Check the TX timestamp.
+	 * Check the Tx timestamp.
 	 */
 	port_ieee1588_tx_timestamp_check(fs->rx_port);
 }
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index c8acd5d..53c0717 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -95,15 +95,15 @@ usage(char* progname)
 	printf("  --portmask=PORTMASK: hexadecimal bitmask of ports used "
 	       "by the packet forwarding test.\n");
 	printf("  --portlist=PORTLIST: list of forwarding ports\n");
-	printf("  --numa: enable NUMA-aware allocation of RX/TX rings and of "
-	       "RX memory buffers (mbufs).\n");
+	printf("  --numa: enable NUMA-aware allocation of Rx/Tx rings and of "
+	       "Rx memory buffers (mbufs).\n");
 	printf("  --port-numa-config=(port,socket)[,(port,socket)]: "
 	       "specify the socket on which the memory pool "
 	       "used by the port will be allocated.\n");
 	printf("  --ring-numa-config=(port,flag,socket)[,(port,flag,socket)]: "
-	       "specify the socket on which the TX/RX rings for "
+	       "specify the socket on which the Tx/Rx rings for "
 	       "the port will be allocated "
-	       "(flag: 1 for RX; 2 for TX; 3 for RX and TX).\n");
+	       "(flag: 1 for Rx; 2 for Tx; 3 for Rx and Tx).\n");
 	printf("  --socket-num=N: set socket from which all memory is allocated "
 	       "in NUMA mode.\n");
 	printf("  --mbuf-size=N,[N1[,..Nn]: set the data size of mbuf to "
@@ -156,32 +156,32 @@ usage(char* progname)
 	printf("  --rss-udp: set RSS functions to IPv4/IPv6 + UDP.\n");
 	printf("  --rss-level-inner: set RSS hash level to innermost\n");
 	printf("  --rss-level-outer: set RSS hash level to outermost\n");
-	printf("  --rxq=N: set the number of RX queues per port to N.\n");
-	printf("  --rxd=N: set the number of descriptors in RX rings to N.\n");
-	printf("  --txq=N: set the number of TX queues per port to N.\n");
-	printf("  --txd=N: set the number of descriptors in TX rings to N.\n");
+	printf("  --rxq=N: set the number of Rx queues per port to N.\n");
+	printf("  --rxd=N: set the number of descriptors in Rx rings to N.\n");
+	printf("  --txq=N: set the number of Tx queues per port to N.\n");
+	printf("  --txd=N: set the number of descriptors in Tx rings to N.\n");
 	printf("  --hairpinq=N: set the number of hairpin queues per port to "
 	       "N.\n");
 	printf("  --burst=N: set the number of packets per burst to N.\n");
 	printf("  --flowgen-clones=N: set the number of single packet clones to send in flowgen mode. Should be less than burst value.\n");
 	printf("  --mbcache=N: set the cache of mbuf memory pool to N.\n");
-	printf("  --rxpt=N: set prefetch threshold register of RX rings to N.\n");
-	printf("  --rxht=N: set the host threshold register of RX rings to N.\n");
-	printf("  --rxfreet=N: set the free threshold of RX descriptors to N "
+	printf("  --rxpt=N: set prefetch threshold register of Rx rings to N.\n");
+	printf("  --rxht=N: set the host threshold register of Rx rings to N.\n");
+	printf("  --rxfreet=N: set the free threshold of Rx descriptors to N "
 	       "(0 <= N < value of rxd).\n");
-	printf("  --rxwt=N: set the write-back threshold register of RX rings to N.\n");
-	printf("  --txpt=N: set the prefetch threshold register of TX rings to N.\n");
-	printf("  --txht=N: set the nhost threshold register of TX rings to N.\n");
-	printf("  --txwt=N: set the write-back threshold register of TX rings to N.\n");
-	printf("  --txfreet=N: set the transmit free threshold of TX rings to N "
+	printf("  --rxwt=N: set the write-back threshold register of Rx rings to N.\n");
+	printf("  --txpt=N: set the prefetch threshold register of Tx rings to N.\n");
+	printf("  --txht=N: set the nhost threshold register of Tx rings to N.\n");
+	printf("  --txwt=N: set the write-back threshold register of Tx rings to N.\n");
+	printf("  --txfreet=N: set the transmit free threshold of Tx rings to N "
 	       "(0 <= N <= value of txd).\n");
-	printf("  --txrst=N: set the transmit RS bit threshold of TX rings to N "
+	printf("  --txrst=N: set the transmit RS bit threshold of Tx rings to N "
 	       "(0 <= N <= value of txd).\n");
-	printf("  --no-flush-rx: Don't flush RX streams before forwarding."
+	printf("  --no-flush-rx: Don't flush Rx streams before forwarding."
 	       " Used mainly with PCAP drivers.\n");
-	printf("  --rxoffs=X[,Y]*: set RX segment offsets for split.\n");
-	printf("  --rxpkts=X[,Y]*: set RX segment sizes to split.\n");
-	printf("  --txpkts=X[,Y]*: set TX segment sizes"
+	printf("  --rxoffs=X[,Y]*: set Rx segment offsets for split.\n");
+	printf("  --rxpkts=X[,Y]*: set Rx segment sizes to split.\n");
+	printf("  --txpkts=X[,Y]*: set Tx segment sizes"
 		" or total packet length.\n");
 	printf("  --txonly-multi-flow: generate multiple flows in txonly mode\n");
 	printf("  --disable-link-check: disable check on link status when "
@@ -197,8 +197,8 @@ usage(char* progname)
 	       "disable print of designated event or all of them.\n");
 	printf("  --flow-isolate-all: "
 	       "requests flow API isolated mode on all ports at initialization time.\n");
-	printf("  --tx-offloads=0xXXXXXXXX: hexadecimal bitmask of TX queue offloads\n");
-	printf("  --rx-offloads=0xXXXXXXXX: hexadecimal bitmask of RX queue offloads\n");
+	printf("  --tx-offloads=0xXXXXXXXX: hexadecimal bitmask of Tx queue offloads\n");
+	printf("  --rx-offloads=0xXXXXXXXX: hexadecimal bitmask of Rx queue offloads\n");
 	printf("  --hot-plug: enable hot plug for device.\n");
 	printf("  --vxlan-gpe-port=N: UPD port of tunnel VXLAN-GPE\n");
 	printf("  --geneve-parsed-port=N: UPD port to parse GENEVE tunnel protocol\n");
@@ -217,10 +217,10 @@ usage(char* progname)
 	printf("  --noisy-lkup-num-writes=N: do N random reads and writes per packet\n");
 	printf("  --no-iova-contig: mempool memory can be IOVA non contiguous. "
 	       "valid only with --mp-alloc=anon\n");
-	printf("  --rx-mq-mode=0xX: hexadecimal bitmask of RX mq mode can be "
+	printf("  --rx-mq-mode=0xX: hexadecimal bitmask of Rx mq mode can be "
 	       "enabled\n");
 	printf("  --record-core-cycles: enable measurement of CPU cycles.\n");
-	printf("  --record-burst-stats: enable display of RX and TX bursts.\n");
+	printf("  --record-burst-stats: enable display of Rx and Tx bursts.\n");
 	printf("  --hairpin-mode=0xXX: bitmask set the hairpin port mode.\n "
 	       "    0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n"
 	       "    0x01 - hairpin ports loop, 0x00 - hairpin port self\n");
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 7eb810b..d83eb8c 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -92,7 +92,7 @@ char cmdline_filename[PATH_MAX] = {0};
 /*
  * NUMA support configuration.
  * When set, the NUMA support attempts to dispatch the allocation of the
- * RX and TX memory rings, and of the DMA memory buffers (mbufs) for the
+ * Rx and Tx memory rings, and of the DMA memory buffers (mbufs) for the
  * probed ports among the CPU sockets 0 and 1.
  * Otherwise, all memory is allocated from CPU socket 0.
  */
@@ -120,7 +120,7 @@ uint8_t mp_alloc_type = MP_ALLOC_NATIVE;
 uint8_t port_numa[RTE_MAX_ETHPORTS];
 
 /*
- * Store specified sockets on which RX ring to be used by ports
+ * Store specified sockets on which Rx ring to be used by ports
  * is allocated.
  */
 uint8_t rxring_numa[RTE_MAX_ETHPORTS];
@@ -163,7 +163,7 @@ portid_t  nb_fwd_ports;  /**< Number of forwarding ports. */
 unsigned int fwd_lcores_cpuids[RTE_MAX_LCORE]; /**< CPU ids configuration. */
 portid_t fwd_ports_ids[RTE_MAX_ETHPORTS];      /**< Port ids configuration. */
 
-struct fwd_stream **fwd_streams; /**< For each RX queue of each port. */
+struct fwd_stream **fwd_streams; /**< For each Rx queue of each port. */
 streamid_t nb_fwd_streams;       /**< Is equal to (nb_ports * nb_rxq). */
 
 /*
@@ -228,7 +228,7 @@ uint16_t tx_pkt_seg_lengths[RTE_MAX_SEGS_PER_PKT] = {
 uint8_t  tx_pkt_nb_segs = 1; /**< Number of segments in TXONLY packets */
 
 enum tx_pkt_split tx_pkt_split = TX_PKT_SPLIT_OFF;
-/**< Split policy for packets to TX. */
+/**< Split policy for packets to Tx. */
 
 uint8_t txonly_multi_flow;
 /**< Whether multiple flows are generated in TXONLY mode. */
@@ -250,24 +250,24 @@ uint8_t dcb_config = 0;
 uint8_t dcb_test = 0;
 
 /*
- * Configurable number of RX/TX queues.
+ * Configurable number of Rx/Tx queues.
  */
 queueid_t nb_hairpinq; /**< Number of hairpin queues per port. */
-queueid_t nb_rxq = 1; /**< Number of RX queues per port. */
-queueid_t nb_txq = 1; /**< Number of TX queues per port. */
+queueid_t nb_rxq = 1; /**< Number of Rx queues per port. */
+queueid_t nb_txq = 1; /**< Number of Tx queues per port. */
 
 /*
- * Configurable number of RX/TX ring descriptors.
+ * Configurable number of Rx/Tx ring descriptors.
  * Defaults are supplied by drivers via ethdev.
  */
 #define RTE_TEST_RX_DESC_DEFAULT 0
 #define RTE_TEST_TX_DESC_DEFAULT 0
-uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT; /**< Number of RX descriptors. */
-uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT; /**< Number of TX descriptors. */
+uint16_t nb_rxd = RTE_TEST_RX_DESC_DEFAULT; /**< Number of Rx descriptors. */
+uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT; /**< Number of Tx descriptors. */
 
 #define RTE_PMD_PARAM_UNSET -1
 /*
- * Configurable values of RX and TX ring threshold registers.
+ * Configurable values of Rx and Tx ring threshold registers.
  */
 
 int8_t rx_pthresh = RTE_PMD_PARAM_UNSET;
@@ -279,22 +279,22 @@ int8_t tx_hthresh = RTE_PMD_PARAM_UNSET;
 int8_t tx_wthresh = RTE_PMD_PARAM_UNSET;
 
 /*
- * Configurable value of RX free threshold.
+ * Configurable value of Rx free threshold.
  */
 int16_t rx_free_thresh = RTE_PMD_PARAM_UNSET;
 
 /*
- * Configurable value of RX drop enable.
+ * Configurable value of Rx drop enable.
  */
 int8_t rx_drop_en = RTE_PMD_PARAM_UNSET;
 
 /*
- * Configurable value of TX free threshold.
+ * Configurable value of Tx free threshold.
  */
 int16_t tx_free_thresh = RTE_PMD_PARAM_UNSET;
 
 /*
- * Configurable value of TX RS bit threshold.
+ * Configurable value of Tx RS bit threshold.
  */
 int16_t tx_rs_thresh = RTE_PMD_PARAM_UNSET;
 
@@ -343,7 +343,7 @@ uint64_t rss_hf = ETH_RSS_IP; /* RSS IP by default. */
 uint16_t port_topology = PORT_TOPOLOGY_PAIRED; /* Ports are paired by default */
 
 /*
- * Avoids to flush all the RX streams before starts forwarding.
+ * Avoids to flush all the Rx streams before starts forwarding.
  */
 uint8_t no_flush_rx = 0; /* flush by default */
 
@@ -491,7 +491,7 @@ uint8_t xstats_hide_zero;
 uint8_t record_core_cycles;
 
 /*
- * Display of RX and TX bursts disabled by default
+ * Display of Rx and Tx bursts disabled by default
  */
 uint8_t record_burst_stats;
 
@@ -509,7 +509,7 @@ struct gro_status gro_ports[RTE_MAX_ETHPORTS];
 uint8_t gro_flush_cycles = GRO_DEFAULT_FLUSH_CYCLES;
 
 /*
- * hexadecimal bitmask of RX mq mode can be enabled.
+ * hexadecimal bitmask of Rx mq mode can be enabled.
  */
 enum rte_eth_rx_mq_mode rx_mq_mode = ETH_MQ_RX_VMDQ_DCB_RSS;
 
@@ -1085,7 +1085,7 @@ check_socket_id(const unsigned int socket_id)
 }
 
 /*
- * Get the allowed maximum number of RX queues.
+ * Get the allowed maximum number of Rx queues.
  * *pid return the port id which has minimal value of
  * max_rx_queues in all ports.
  */
@@ -1113,7 +1113,7 @@ get_allowed_max_nb_rxq(portid_t *pid)
 /*
  * Check input rxq is valid or not.
  * If input rxq is not greater than any of maximum number
- * of RX queues of all ports, it is valid.
+ * of Rx queues of all ports, it is valid.
  * if valid, return 0, else return -1
  */
 int
@@ -1135,7 +1135,7 @@ check_nb_rxq(queueid_t rxq)
 }
 
 /*
- * Get the allowed maximum number of TX queues.
+ * Get the allowed maximum number of Tx queues.
  * *pid return the port id which has minimal value of
  * max_tx_queues in all ports.
  */
@@ -1163,7 +1163,7 @@ get_allowed_max_nb_txq(portid_t *pid)
 /*
  * Check input txq is valid or not.
  * If input txq is not greater than any of maximum number
- * of TX queues of all ports, it is valid.
+ * of Tx queues of all ports, it is valid.
  * if valid, return 0, else return -1
  */
 int
@@ -1185,7 +1185,7 @@ check_nb_txq(queueid_t txq)
 }
 
 /*
- * Get the allowed maximum number of RXDs of every rx queue.
+ * Get the allowed maximum number of RXDs of every Rx queue.
  * *pid return the port id which has minimal value of
  * max_rxd in all queues of all ports.
  */
@@ -1209,7 +1209,7 @@ get_allowed_max_nb_rxd(portid_t *pid)
 }
 
 /*
- * Get the allowed minimal number of RXDs of every rx queue.
+ * Get the allowed minimal number of RXDs of every Rx queue.
  * *pid return the port id which has minimal value of
  * min_rxd in all queues of all ports.
  */
@@ -1271,9 +1271,9 @@ check_nb_rxd(queueid_t rxd)
 }
 
 /*
- * Get the allowed maximum number of TXDs of every rx queues.
+ * Get the allowed maximum number of TXDs of every Rx queues.
  * *pid return the port id which has minimal value of
- * max_txd in every tx queue.
+ * max_txd in every Tx queue.
  */
 static uint16_t
 get_allowed_max_nb_txd(portid_t *pid)
@@ -1295,9 +1295,9 @@ get_allowed_max_nb_txd(portid_t *pid)
 }
 
 /*
- * Get the allowed maximum number of TXDs of every tx queues.
+ * Get the allowed maximum number of TXDs of every Tx queues.
  * *pid return the port id which has minimal value of
- * min_txd in every tx queue.
+ * min_txd in every Tx queue.
  */
 static uint16_t
 get_allowed_min_nb_txd(portid_t *pid)
@@ -1781,30 +1781,30 @@ fwd_stream_stats_display(streamid_t stream_id)
 	if ((fs->rx_packets == 0) && (fs->tx_packets == 0) &&
 	    (fs->fwd_dropped == 0))
 		return;
-	printf("\n  %s Forward Stats for RX Port=%2d/Queue=%2d -> "
-	       "TX Port=%2d/Queue=%2d %s\n",
+	printf("\n  %s Forward Stats for Rx Port=%2d/Queue=%2d -> "
+	       "Tx Port=%2d/Queue=%2d %s\n",
 	       fwd_top_stats_border, fs->rx_port, fs->rx_queue,
 	       fs->tx_port, fs->tx_queue, fwd_top_stats_border);
-	printf("  RX-packets: %-14"PRIu64" TX-packets: %-14"PRIu64
-	       " TX-dropped: %-14"PRIu64,
+	printf("  Rx-packets: %-14"PRIu64" Tx-packets: %-14"PRIu64
+	       " Tx-dropped: %-14"PRIu64,
 	       fs->rx_packets, fs->tx_packets, fs->fwd_dropped);
 
 	/* if checksum mode */
 	if (cur_fwd_eng == &csum_fwd_engine) {
-		printf("  RX- bad IP checksum: %-14"PRIu64
+		printf("  Rx- bad IP checksum: %-14"PRIu64
 		       "  Rx- bad L4 checksum: %-14"PRIu64
 		       " Rx- bad outer L4 checksum: %-14"PRIu64"\n",
 			fs->rx_bad_ip_csum, fs->rx_bad_l4_csum,
 			fs->rx_bad_outer_l4_csum);
-		printf(" RX- bad outer IP checksum: %-14"PRIu64"\n",
+		printf(" Rx- bad outer IP checksum: %-14"PRIu64"\n",
 			fs->rx_bad_outer_ip_csum);
 	} else {
 		printf("\n");
 	}
 
 	if (record_burst_stats) {
-		pkt_burst_stats_display("RX", &fs->rx_burst_stats);
-		pkt_burst_stats_display("TX", &fs->tx_burst_stats);
+		pkt_burst_stats_display("Rx", &fs->rx_burst_stats);
+		pkt_burst_stats_display("Tx", &fs->tx_burst_stats);
 	}
 }
 
@@ -1882,8 +1882,8 @@ fwd_stats_display(void)
 		printf("\n  %s Forward statistics for port %-2d %s\n",
 		       fwd_stats_border, pt_id, fwd_stats_border);
 
-		printf("  RX-packets: %-14"PRIu64" RX-dropped: %-14"PRIu64
-		       "RX-total: %-"PRIu64"\n", stats.ipackets, stats.imissed,
+		printf("  Rx-packets: %-14"PRIu64" Rx-dropped: %-14"PRIu64
+		       "Rx-total: %-"PRIu64"\n", stats.ipackets, stats.imissed,
 		       stats.ipackets + stats.imissed);
 
 		if (cur_fwd_eng == &csum_fwd_engine) {
@@ -1897,21 +1897,21 @@ fwd_stats_display(void)
 			       ports_stats[pt_id].rx_bad_outer_ip_csum);
 		}
 		if (stats.ierrors + stats.rx_nombuf > 0) {
-			printf("  RX-error: %-"PRIu64"\n", stats.ierrors);
-			printf("  RX-nombufs: %-14"PRIu64"\n", stats.rx_nombuf);
+			printf("  Rx-error: %-"PRIu64"\n", stats.ierrors);
+			printf("  Rx-nombufs: %-14"PRIu64"\n", stats.rx_nombuf);
 		}
 
-		printf("  TX-packets: %-14"PRIu64" TX-dropped: %-14"PRIu64
-		       "TX-total: %-"PRIu64"\n",
+		printf("  Tx-packets: %-14"PRIu64" Tx-dropped: %-14"PRIu64
+		       "Tx-total: %-"PRIu64"\n",
 		       stats.opackets, ports_stats[pt_id].tx_dropped,
 		       stats.opackets + ports_stats[pt_id].tx_dropped);
 
 		if (record_burst_stats) {
 			if (ports_stats[pt_id].rx_stream)
-				pkt_burst_stats_display("RX",
+				pkt_burst_stats_display("Rx",
 					&ports_stats[pt_id].rx_stream->rx_burst_stats);
 			if (ports_stats[pt_id].tx_stream)
-				pkt_burst_stats_display("TX",
+				pkt_burst_stats_display("Tx",
 				&ports_stats[pt_id].tx_stream->tx_burst_stats);
 		}
 
@@ -1922,14 +1922,14 @@ fwd_stats_display(void)
 	printf("\n  %s Accumulated forward statistics for all ports"
 	       "%s\n",
 	       acc_stats_border, acc_stats_border);
-	printf("  RX-packets: %-14"PRIu64" RX-dropped: %-14"PRIu64"RX-total: "
+	printf("  Rx-packets: %-14"PRIu64" Rx-dropped: %-14"PRIu64"Rx-total: "
 	       "%-"PRIu64"\n"
-	       "  TX-packets: %-14"PRIu64" TX-dropped: %-14"PRIu64"TX-total: "
+	       "  Tx-packets: %-14"PRIu64" Tx-dropped: %-14"PRIu64"Tx-total: "
 	       "%-"PRIu64"\n",
 	       total_recv, total_rx_dropped, total_recv + total_rx_dropped,
 	       total_xmit, total_tx_dropped, total_xmit + total_tx_dropped);
 	if (total_rx_nombuf > 0)
-		printf("  RX-nombufs: %-14"PRIu64"\n", total_rx_nombuf);
+		printf("  Rx-nombufs: %-14"PRIu64"\n", total_rx_nombuf);
 	printf("  %s++++++++++++++++++++++++++++++++++++++++++++++"
 	       "%s\n",
 	       acc_stats_border, acc_stats_border);
@@ -2337,7 +2337,7 @@ setup_hairpin_queues(portid_t pi, portid_t p_pi, uint16_t cnt_pi)
 		} else {
 			uint16_t next_pi;
 
-			/* Last port will be the peer RX port of the first. */
+			/* Last port will be the peer Rx port of the first. */
 			RTE_ETH_FOREACH_DEV(next_pi)
 				peer_rx_port = next_pi;
 		}
@@ -2366,7 +2366,7 @@ setup_hairpin_queues(portid_t pi, portid_t p_pi, uint16_t cnt_pi)
 		if (diag == 0)
 			continue;
 
-		/* Fail to setup rx queue, return */
+		/* Fail to setup Rx queue, return */
 		if (rte_atomic16_cmpset(&(port->port_status),
 					RTE_PORT_HANDLING,
 					RTE_PORT_STOPPED) == 0)
@@ -2389,7 +2389,7 @@ setup_hairpin_queues(portid_t pi, portid_t p_pi, uint16_t cnt_pi)
 		if (diag == 0)
 			continue;
 
-		/* Fail to setup rx queue, return */
+		/* Fail to setup Rx queue, return */
 		if (rte_atomic16_cmpset(&(port->port_status),
 					RTE_PORT_HANDLING,
 					RTE_PORT_STOPPED) == 0)
@@ -2536,27 +2536,27 @@ start_port(portid_t pid)
 				if (diag == 0)
 					continue;
 
-				/* Fail to setup tx queue, return */
+				/* Fail to setup Tx queue, return */
 				if (rte_atomic16_cmpset(&(port->port_status),
 							RTE_PORT_HANDLING,
 							RTE_PORT_STOPPED) == 0)
 					printf("Port %d can not be set back "
 							"to stopped\n", pi);
-				printf("Fail to configure port %d tx queues\n",
+				printf("Fail to configure port %d Tx queues\n",
 				       pi);
 				/* try to reconfigure queues next time */
 				port->need_reconfig_queues = 1;
 				return -1;
 			}
 			for (qi = 0; qi < nb_rxq; qi++) {
-				/* setup rx queues */
+				/* setup Rx queues */
 				if ((numa_support) &&
 					(rxring_numa[pi] != NUMA_NO_CONFIG)) {
 					struct rte_mempool * mp =
 						mbuf_pool_find
 							(rxring_numa[pi], 0);
 					if (mp == NULL) {
-						printf("Failed to setup RX queue:"
+						printf("Failed to setup Rx queue:"
 							"No mempool allocation"
 							" on the socket %d\n",
 							rxring_numa[pi]);
@@ -2573,7 +2573,7 @@ start_port(portid_t pid)
 						mbuf_pool_find
 							(port->socket_id, 0);
 					if (mp == NULL) {
-						printf("Failed to setup RX queue:"
+						printf("Failed to setup Rx queue:"
 							"No mempool allocation"
 							" on the socket %d\n",
 							port->socket_id);
@@ -2588,13 +2588,13 @@ start_port(portid_t pid)
 				if (diag == 0)
 					continue;
 
-				/* Fail to setup rx queue, return */
+				/* Fail to setup Rx queue, return */
 				if (rte_atomic16_cmpset(&(port->port_status),
 							RTE_PORT_HANDLING,
 							RTE_PORT_STOPPED) == 0)
 					printf("Port %d can not be set back "
 							"to stopped\n", pi);
-				printf("Fail to configure port %d rx queues\n",
+				printf("Fail to configure port %d Rx queues\n",
 				       pi);
 				/* try to reconfigure queues next time */
 				port->need_reconfig_queues = 1;
@@ -3542,7 +3542,7 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
 		struct rte_eth_vmdq_dcb_tx_conf *vmdq_tx_conf =
 				&eth_conf->tx_adv_conf.vmdq_dcb_tx_conf;
 
-		/* VMDQ+DCB RX and TX configurations */
+		/* VMDQ+DCB Rx and Tx configurations */
 		vmdq_rx_conf->enable_default_pool = 0;
 		vmdq_rx_conf->default_pool = 0;
 		vmdq_rx_conf->nb_queue_pools =
@@ -3561,7 +3561,7 @@ get_eth_dcb_conf(portid_t pid, struct rte_eth_conf *eth_conf,
 			vmdq_tx_conf->dcb_tc[i] = i % num_tcs;
 		}
 
-		/* set DCB mode of RX and TX of multiple queues */
+		/* set DCB mode of Rx and Tx of multiple queues */
 		eth_conf->rxmode.mq_mode =
 				(enum rte_eth_rx_mq_mode)
 					(rx_mq_mode & ETH_MQ_RX_VMDQ_DCB);
@@ -3844,7 +3844,7 @@ main(int argc, char** argv)
 	}
 
 	if (!nb_rxq && !nb_txq)
-		printf("Warning: Either rx or tx queues should be non-zero\n");
+		printf("Warning: Either Rx or Tx queues should be non-zero\n");
 
 	if (nb_rxq > 1 && nb_rxq > nb_txq)
 		printf("Warning: nb_rxq=%d enables RSS configuration, "
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index ce83f31..e5e7392 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -88,7 +88,7 @@ enum {
 };
 
 /**
- * The data structure associated with RX and TX packet burst statistics
+ * The data structure associated with Rx and Tx packet burst statistics
  * that are recorded for each forwarding stream.
  */
 struct pkt_burst_stats {
@@ -122,9 +122,9 @@ extern char dynf_names[64][RTE_MBUF_DYN_NAMESIZE];
 struct fwd_stream {
 	/* "read-only" data */
 	portid_t   rx_port;   /**< port to poll for received packets */
-	queueid_t  rx_queue;  /**< RX queue to poll on "rx_port" */
+	queueid_t  rx_queue;  /**< Rx queue to poll on "rx_port" */
 	portid_t   tx_port;   /**< forwarding port of received packets */
-	queueid_t  tx_queue;  /**< TX queue to send forwarded packets */
+	queueid_t  tx_queue;  /**< Tx queue to send forwarded packets */
 	streamid_t peer_addr; /**< index of peer ethernet address of packets */
 
 	unsigned int retry_enabled;
@@ -140,7 +140,7 @@ struct fwd_stream {
 	uint64_t rx_bad_outer_ip_csum;
 	/**< received packets having bad outer ip checksum */
 	unsigned int gro_times;	/**< GRO operation times */
-	uint64_t     core_cycles; /**< used for RX and TX processing */
+	uint64_t     core_cycles; /**< used for Rx and Tx processing */
 	struct pkt_burst_stats rx_burst_stats;
 	struct pkt_burst_stats tx_burst_stats;
 };
@@ -214,10 +214,10 @@ struct rte_port {
 	uint8_t                 need_reconfig_queues; /**< need reconfiguring queues or not */
 	uint8_t                 rss_flag;   /**< enable rss or not */
 	uint8_t                 dcb_flag;   /**< enable dcb */
-	uint16_t                nb_rx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue rx desc number */
-	uint16_t                nb_tx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue tx desc number */
-	struct rte_eth_rxconf   rx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue rx configuration */
-	struct rte_eth_txconf   tx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue tx configuration */
+	uint16_t                nb_rx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue Rx desc number */
+	uint16_t                nb_tx_desc[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue Tx desc number */
+	struct rte_eth_rxconf   rx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue Rx configuration */
+	struct rte_eth_txconf   tx_conf[RTE_MAX_QUEUES_PER_PORT+1]; /**< per queue Tx configuration */
 	struct rte_ether_addr   *mc_addr_pool; /**< pool of multicast addrs */
 	uint32_t                mc_addr_nb; /**< nb. of addr. in mc_addr_pool */
 	uint8_t                 slave_flag; /**< bonding slave port */
@@ -329,7 +329,7 @@ extern uint8_t xstats_hide_zero; /**< Hide zero values for xstats display */
 
 /* globals used for configuration */
 extern uint8_t record_core_cycles; /**< Enables measurement of CPU cycles */
-extern uint8_t record_burst_stats; /**< Enables display of RX and TX bursts */
+extern uint8_t record_burst_stats; /**< Enables display of Rx and Tx bursts */
 extern uint16_t verbose_level; /**< Drives messages being displayed, if any. */
 extern int testpmd_logtype; /**< Log type for testpmd logs */
 extern uint8_t  interactive;
@@ -365,13 +365,13 @@ extern uint32_t bypass_timeout; /**< Store the NIC bypass watchdog timeout */
 extern uint8_t port_numa[RTE_MAX_ETHPORTS];
 
 /*
- * Store specified sockets on which RX ring to be used by ports
+ * Store specified sockets on which Rx ring to be used by ports
  * is allocated.
  */
 extern uint8_t rxring_numa[RTE_MAX_ETHPORTS];
 
 /*
- * Store specified sockets on which TX ring to be used by ports
+ * Store specified sockets on which Tx ring to be used by ports
  * is allocated.
  */
 extern uint8_t txring_numa[RTE_MAX_ETHPORTS];
@@ -462,7 +462,7 @@ extern uint8_t  rx_pkt_nb_offs; /**< Number of specified offsets */
 #define TXONLY_DEF_PACKET_LEN 64
 extern uint16_t tx_pkt_length; /**< Length of TXONLY packet */
 extern uint16_t tx_pkt_seg_lengths[RTE_MAX_SEGS_PER_PKT]; /**< Seg. lengths */
-extern uint8_t  tx_pkt_nb_segs; /**< Number of segments in TX packets */
+extern uint8_t  tx_pkt_nb_segs; /**< Number of segments in Tx packets */
 extern uint32_t tx_pkt_times_intra;
 extern uint32_t tx_pkt_times_inter;
 
@@ -504,8 +504,8 @@ extern uint16_t geneve_udp_port; /**< UDP port of tunnel GENEVE. */
 extern portid_t nb_peer_eth_addrs; /**< Number of peer ethernet addresses. */
 extern struct rte_ether_addr peer_eth_addrs[RTE_MAX_ETHPORTS];
 
-extern uint32_t burst_tx_delay_time; /**< Burst tx delay time(us) for mac-retry. */
-extern uint32_t burst_tx_retry_num;  /**< Burst tx retry number for mac-retry. */
+extern uint32_t burst_tx_delay_time; /**< Burst Tx delay time(us) for mac-retry. */
+extern uint32_t burst_tx_retry_num;  /**< Burst Tx retry number for mac-retry. */
 
 #define GRO_DEFAULT_ITEM_NUM_PER_FLOW 32
 #define GRO_DEFAULT_FLOW_NUM (RTE_GRO_MAX_BURST_ITEM_NUM / \
diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index d55ee7c..f41823f 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -52,7 +52,7 @@ uint32_t tx_ip_dst_addr = (198U << 24) | (18 << 16) | (0 << 8) | 2;
 
 static struct rte_ipv4_hdr pkt_ip_hdr; /**< IP header of transmitted packets. */
 RTE_DEFINE_PER_LCORE(uint8_t, _ip_var); /**< IP address variation */
-static struct rte_udp_hdr pkt_udp_hdr; /**< UDP header of tx packets. */
+static struct rte_udp_hdr pkt_udp_hdr; /**< UDP header of Tx packets. */
 RTE_DEFINE_PER_LCORE(uint64_t, timestamp_qskew);
 					/**< Timestamp offset per queue */
 RTE_DEFINE_PER_LCORE(uint32_t, timestamp_idone); /**< Timestamp init done. */
-- 
2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Li, Xiaoyun]

Hi

> -----Original Message-----
> From: Lijun Ou <oulijun@huawei.com>
> Sent: Friday, March 5, 2021 18:22
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> linuxarm@openeuler.org
> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> 
> From: Hongbo Zheng <zhenghongbo3@huawei.com>
> 
> In testpmd, when we input "show config rxtx", we can see like this:
> 
> 1: testpmd> show config rxtx
> 2:   io packet forwarding packets/burst=32
> 3:   nb forwarding cores=1 - nb forwarding ports=1
> 4:   port 0: RX queue number: 1 Tx queue number: 1
> 5:     Rx offloads=0x0 Tx offloads=0x10000
> 6:     RX queue: 0
> 7:       RX desc=1024 - RX free threshold=32
> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
> 9:       RX Offloads=0x0
> 10:    TX queue: 0
> 11:      TX desc=1024 - TX free threshold=928
> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
> 13:      TX offloads=0x10000 - TX RS bit threshold=32
> 
> We can see RX/Rx/TX/Tx is mixed used. Also in other places in testpmd,
> RX/Rx/TX/Tx is mixed used.
> 
> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change
> to unified use Rx/Tx.

The commit log is too redundant. The following is enough to explain what this patch does:
RX/TX and Rx/Tx are mixed used in testpmd print and comments. This patch unifies them as Rx/Tx.

Except this, the patch looks good to me.

But one big concern, this patch will break all of the CI tests because the DTS scripts check if the results are the same as expected and this patch change a lot of the print.
So I think the DTS maintainer needs to be aware of this.

+Lijuan DTS maintainer

> 
> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
> V1->V2:
> - fix all RX/TX
> - rename patch title
> ---
>  app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
>  app/test-pmd/config.c      | 128 ++++++++++++++++++++++-----------------------
>  app/test-pmd/csumonly.c    |  22 ++++----
>  app/test-pmd/icmpecho.c    |   2 +-
>  app/test-pmd/ieee1588fwd.c |  18 +++----
>  app/test-pmd/parameters.c  |  50 +++++++++---------
>  app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
>  app/test-pmd/testpmd.h     |  28 +++++-----
>  app/test-pmd/txonly.c      |   2 +-
>  9 files changed, 237 insertions(+), 237 deletions(-)
> --
> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Li, Xiaoyun]

Hi

> -----Original Message-----
> From: Lijun Ou <oulijun@huawei.com>
> Sent: Friday, March 5, 2021 18:22
> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> linuxarm@openeuler.org
> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>
> From: Hongbo Zheng <zhenghongbo3@huawei.com>
>
> In testpmd, when we input "show config rxtx", we can see like this:
>
> 1: testpmd> show config rxtx
> 2:   io packet forwarding packets/burst=32
> 3:   nb forwarding cores=1 - nb forwarding ports=1
> 4:   port 0: RX queue number: 1 Tx queue number: 1
> 5:     Rx offloads=0x0 Tx offloads=0x10000
> 6:     RX queue: 0
> 7:       RX desc=1024 - RX free threshold=32
> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
> 9:       RX Offloads=0x0
> 10:    TX queue: 0
> 11:      TX desc=1024 - TX free threshold=928
> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
> 13:      TX offloads=0x10000 - TX RS bit threshold=32
>
> We can see RX/Rx/TX/Tx is mixed used. Also in other places in testpmd,
> RX/Rx/TX/Tx is mixed used.
>
> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
> unified use Rx/Tx.

The commit log is too redundant. The following is enough to explain what this patch does:
RX/TX and Rx/Tx are mixed used in testpmd print and comments. This patch unifies them as Rx/Tx.

Except this, the patch looks good to me.

But one big concern, this patch will break all of the CI tests because the DTS scripts check if the results are the same as expected and this patch change a lot of the print.
So I think the DTS maintainer needs to be aware of this.

+Lijuan DTS maintainer

And please separate this patch with the other twos. Don't mix them in one patchset. It's not for the same purpose.

>
> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
> V1->V2:
> - fix all RX/TX
> - rename patch title
> ---
>  app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
>  app/test-pmd/config.c      | 128 ++++++++++++++++++++++-----------------------
>  app/test-pmd/csumonly.c    |  22 ++++----
>  app/test-pmd/icmpecho.c    |   2 +-
>  app/test-pmd/ieee1588fwd.c |  18 +++----  app/test-pmd/parameters.c
> |  50 +++++++++---------
>  app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
>  app/test-pmd/testpmd.h     |  28 +++++-----
>  app/test-pmd/txonly.c      |   2 +-
>  9 files changed, 237 insertions(+), 237 deletions(-)
> --
> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Andrew Rybchenko]

On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
> Hi
> 
>> -----Original Message-----
>> From: Lijun Ou <oulijun@huawei.com>
>> Sent: Friday, March 5, 2021 18:22
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>> linuxarm@openeuler.org
>> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>>
>> From: Hongbo Zheng <zhenghongbo3@huawei.com>
>>
>> In testpmd, when we input "show config rxtx", we can see like this:
>>
>> 1: testpmd> show config rxtx
>> 2:   io packet forwarding packets/burst=32
>> 3:   nb forwarding cores=1 - nb forwarding ports=1
>> 4:   port 0: RX queue number: 1 Tx queue number: 1
>> 5:     Rx offloads=0x0 Tx offloads=0x10000
>> 6:     RX queue: 0
>> 7:       RX desc=1024 - RX free threshold=32
>> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
>> 9:       RX Offloads=0x0
>> 10:    TX queue: 0
>> 11:      TX desc=1024 - TX free threshold=928
>> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
>> 13:      TX offloads=0x10000 - TX RS bit threshold=32
>>
>> We can see RX/Rx/TX/Tx is mixed used. Also in other places in testpmd,
>> RX/Rx/TX/Tx is mixed used.
>>
>> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
>> unified use Rx/Tx.
> 
> The commit log is too redundant. The following is enough to explain what this patch does:
> RX/TX and Rx/Tx are mixed used in testpmd print and comments. This patch unifies them as Rx/Tx.
> 
> Except this, the patch looks good to me.
> 
> But one big concern, this patch will break all of the CI tests because the DTS scripts check if the results are the same as expected and this patch change a lot of the print.
> So I think the DTS maintainer needs to be aware of this.

I think test dpdk-testpmd output is a part of API. Of course,
it is not an API, but such cosmetic changes in output will
be much more painful than API changes. Output parsers will
simply stop to work. I think such changes should go through
the deprecation process.

Of course, it would be useful to change comments and may be
even error log messages right now, but not commands output.

> 
> +Lijuan DTS maintainer
> 
> And please separate this patch with the other twos. Don't mix them in one patchset. It's not for the same purpose.
> 
>>
>> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>> V1->V2:
>> - fix all RX/TX
>> - rename patch title
>> ---
>>  app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
>>  app/test-pmd/config.c      | 128 ++++++++++++++++++++++-----------------------
>>  app/test-pmd/csumonly.c    |  22 ++++----
>>  app/test-pmd/icmpecho.c    |   2 +-
>>  app/test-pmd/ieee1588fwd.c |  18 +++----  app/test-pmd/parameters.c
>> |  50 +++++++++---------
>>  app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
>>  app/test-pmd/testpmd.h     |  28 +++++-----
>>  app/test-pmd/txonly.c      |   2 +-
>>  9 files changed, 237 insertions(+), 237 deletions(-)
>> --
>> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Tu, Lijuan]

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: 2021年3月23日 15:25
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Lijun Ou <oulijun@huawei.com>; Yigit,
> Ferruh <ferruh.yigit@intel.com>; Tu, Lijuan <lijuan.tu@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> 
> On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
> > Hi
> >
> >> -----Original Message-----
> >> From: Lijun Ou <oulijun@huawei.com>
> >> Sent: Friday, March 5, 2021 18:22
> >> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >> linuxarm@openeuler.org
> >> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> >>
> >> From: Hongbo Zheng <zhenghongbo3@huawei.com>
> >>
> >> In testpmd, when we input "show config rxtx", we can see like this:
> >>
> >> 1: testpmd> show config rxtx
> >> 2:   io packet forwarding packets/burst=32
> >> 3:   nb forwarding cores=1 - nb forwarding ports=1
> >> 4:   port 0: RX queue number: 1 Tx queue number: 1
> >> 5:     Rx offloads=0x0 Tx offloads=0x10000
> >> 6:     RX queue: 0
> >> 7:       RX desc=1024 - RX free threshold=32
> >> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >> 9:       RX Offloads=0x0
> >> 10:    TX queue: 0
> >> 11:      TX desc=1024 - TX free threshold=928
> >> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >> 13:      TX offloads=0x10000 - TX RS bit threshold=32
> >>
> >> We can see RX/Rx/TX/Tx is mixed used. Also in other places in
> >> testpmd, RX/Rx/TX/Tx is mixed used.
> >>
> >> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
> >> unified use Rx/Tx.
> >
> > The commit log is too redundant. The following is enough to explain what this
> patch does:
> > RX/TX and Rx/Tx are mixed used in testpmd print and comments. This patch
> unifies them as Rx/Tx.
> >
> > Except this, the patch looks good to me.
> >
> > But one big concern, this patch will break all of the CI tests because the DTS
> scripts check if the results are the same as expected and this patch change a lot
> of the print.
> > So I think the DTS maintainer needs to be aware of this.
> 
> I think test dpdk-testpmd output is a part of API. Of course, it is not an API, but
> such cosmetic changes in output will be much more painful than API changes.
> Output parsers will simply stop to work. I think such changes should go through
> the deprecation process.
> 
> Of course, it would be useful to change comments and may be even error log
> messages right now, but not commands output.
> 
> >
> > +Lijuan DTS maintainer

It has big impact with CI system, most of test cases depended on the testpmd output, if changed, our CI system will be broken, Is it really worth it ?

> >
> > And please separate this patch with the other twos. Don't mix them in one
> patchset. It's not for the same purpose.
> >
> >>
> >> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
> >> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >> ---
> >> V1->V2:
> >> - fix all RX/TX
> >> - rename patch title
> >> ---
> >>  app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
> >>  app/test-pmd/config.c      | 128 ++++++++++++++++++++++---------------------
> --
> >>  app/test-pmd/csumonly.c    |  22 ++++----
> >>  app/test-pmd/icmpecho.c    |   2 +-
> >>  app/test-pmd/ieee1588fwd.c |  18 +++----  app/test-pmd/parameters.c
> >> |  50 +++++++++---------
> >>  app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
> >>  app/test-pmd/testpmd.h     |  28 +++++-----
> >>  app/test-pmd/txonly.c      |   2 +-
> >>  9 files changed, 237 insertions(+), 237 deletions(-)
> >> --
> >> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[oulijun]

在 2021/3/23 15:46, Tu, Lijuan 写道:
> 
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: 2021年3月23日 15:25
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Lijun Ou <oulijun@huawei.com>; Yigit,
>> Ferruh <ferruh.yigit@intel.com>; Tu, Lijuan <lijuan.tu@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>>
>> On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
>>> Hi
>>>
>>>> -----Original Message-----
>>>> From: Lijun Ou <oulijun@huawei.com>
>>>> Sent: Friday, March 5, 2021 18:22
>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>> linuxarm@openeuler.org
>>>> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>>>>
>>>> From: Hongbo Zheng <zhenghongbo3@huawei.com>
>>>>
>>>> In testpmd, when we input "show config rxtx", we can see like this:
>>>>
>>>> 1: testpmd> show config rxtx
>>>> 2:   io packet forwarding packets/burst=32
>>>> 3:   nb forwarding cores=1 - nb forwarding ports=1
>>>> 4:   port 0: RX queue number: 1 Tx queue number: 1
>>>> 5:     Rx offloads=0x0 Tx offloads=0x10000
>>>> 6:     RX queue: 0
>>>> 7:       RX desc=1024 - RX free threshold=32
>>>> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
>>>> 9:       RX Offloads=0x0
>>>> 10:    TX queue: 0
>>>> 11:      TX desc=1024 - TX free threshold=928
>>>> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
>>>> 13:      TX offloads=0x10000 - TX RS bit threshold=32
>>>>
>>>> We can see RX/Rx/TX/Tx is mixed used. Also in other places in
>>>> testpmd, RX/Rx/TX/Tx is mixed used.
>>>>
>>>> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
>>>> unified use Rx/Tx.
>>>
>>> The commit log is too redundant. The following is enough to explain what this
>> patch does:
>>> RX/TX and Rx/Tx are mixed used in testpmd print and comments. This patch
>> unifies them as Rx/Tx.
>>>
>>> Except this, the patch looks good to me.
>>>
>>> But one big concern, this patch will break all of the CI tests because the DTS
>> scripts check if the results are the same as expected and this patch change a lot
>> of the print.
>>> So I think the DTS maintainer needs to be aware of this.
>>
>> I think test dpdk-testpmd output is a part of API. Of course, it is not an API, but
>> such cosmetic changes in output will be much more painful than API changes.
>> Output parsers will simply stop to work. I think such changes should go through
>> the deprecation process.
>>
>> Of course, it would be useful to change comments and may be even error log
>> messages right now, but not commands output.
>>
>>>
>>> +Lijuan DTS maintainer
> 
> It has big impact with CI system, most of test cases depended on the testpmd output, if changed, our CI system will be broken, Is it really worth it ?
> 
I think it's necessary to keep the style consistent and to constrain 
everyone to do so in the future.However, if the DTS changes greatly, I 
think it is possible to require the new print to be consistent and the 
historical part to remain unchanged.Because the uniform change is also 
Xiaoyun's suggestion, we think the opinion is reasonable, but we are not 
sure how much it will affect DTS.
>>>
>>> And please separate this patch with the other twos. Don't mix them in one
>> patchset. It's not for the same purpose.
>>>
>>>>
>>>> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> ---
>>>> V1->V2:
>>>> - fix all RX/TX
>>>> - rename patch title
>>>> ---
>>>>   app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
>>>>   app/test-pmd/config.c      | 128 ++++++++++++++++++++++---------------------
>> --
>>>>   app/test-pmd/csumonly.c    |  22 ++++----
>>>>   app/test-pmd/icmpecho.c    |   2 +-
>>>>   app/test-pmd/ieee1588fwd.c |  18 +++----  app/test-pmd/parameters.c
>>>> |  50 +++++++++---------
>>>>   app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++---------------------
>>>>   app/test-pmd/testpmd.h     |  28 +++++-----
>>>>   app/test-pmd/txonly.c      |   2 +-
>>>>   9 files changed, 237 insertions(+), 237 deletions(-)
>>>> --
>>>> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Li, Xiaoyun]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: Tuesday, March 23, 2021 15:52
> To: Tu, Lijuan <lijuan.tu@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit,
> Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> 
> 
> 
> 在 2021/3/23 15:46, Tu, Lijuan 写道:
> >
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >> Sent: 2021年3月23日 15:25
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Lijun Ou
> >> <oulijun@huawei.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Tu,
> >> Lijuan <lijuan.tu@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in
> >> testpmd
> >>
> >> On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
> >>> Hi
> >>>
> >>>> -----Original Message-----
> >>>> From: Lijun Ou <oulijun@huawei.com>
> >>>> Sent: Friday, March 5, 2021 18:22
> >>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >>>> linuxarm@openeuler.org
> >>>> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> >>>>
> >>>> From: Hongbo Zheng <zhenghongbo3@huawei.com>
> >>>>
> >>>> In testpmd, when we input "show config rxtx", we can see like this:
> >>>>
> >>>> 1: testpmd> show config rxtx
> >>>> 2:   io packet forwarding packets/burst=32
> >>>> 3:   nb forwarding cores=1 - nb forwarding ports=1
> >>>> 4:   port 0: RX queue number: 1 Tx queue number: 1
> >>>> 5:     Rx offloads=0x0 Tx offloads=0x10000
> >>>> 6:     RX queue: 0
> >>>> 7:       RX desc=1024 - RX free threshold=32
> >>>> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >>>> 9:       RX Offloads=0x0
> >>>> 10:    TX queue: 0
> >>>> 11:      TX desc=1024 - TX free threshold=928
> >>>> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >>>> 13:      TX offloads=0x10000 - TX RS bit threshold=32
> >>>>
> >>>> We can see RX/Rx/TX/Tx is mixed used. Also in other places in
> >>>> testpmd, RX/Rx/TX/Tx is mixed used.
> >>>>
> >>>> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
> >>>> unified use Rx/Tx.
> >>>
> >>> The commit log is too redundant. The following is enough to explain
> >>> what this
> >> patch does:
> >>> RX/TX and Rx/Tx are mixed used in testpmd print and comments. This
> >>> patch
> >> unifies them as Rx/Tx.
> >>>
> >>> Except this, the patch looks good to me.
> >>>
> >>> But one big concern, this patch will break all of the CI tests
> >>> because the DTS
> >> scripts check if the results are the same as expected and this patch
> >> change a lot of the print.
> >>> So I think the DTS maintainer needs to be aware of this.
> >>
> >> I think test dpdk-testpmd output is a part of API. Of course, it is
> >> not an API, but such cosmetic changes in output will be much more painful
> than API changes.
> >> Output parsers will simply stop to work. I think such changes should
> >> go through the deprecation process.
> >>
> >> Of course, it would be useful to change comments and may be even
> >> error log messages right now, but not commands output.
> >>
> >>>
> >>> +Lijuan DTS maintainer
> >
> > It has big impact with CI system, most of test cases depended on the testpmd
> output, if changed, our CI system will be broken, Is it really worth it ?
> >
> I think it's necessary to keep the style consistent and to constrain everyone to do
> so in the future.However, if the DTS changes greatly, I think it is possible to
> require the new print to be consistent and the historical part to remain
> unchanged.Because the uniform change is also Xiaoyun's suggestion, we think
> the opinion is reasonable, but we are not sure how much it will affect DTS.

I think we should drop this patch. But we'll keep consistent for future print when reviewing.
What do you think?

> >>>
> >>> And please separate this patch with the other twos. Don't mix them
> >>> in one
> >> patchset. It's not for the same purpose.
> >>>
> >>>>
> >>>> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
> >>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>>> ---
> >>>> V1->V2:
> >>>> - fix all RX/TX
> >>>> - rename patch title
> >>>> ---
> >>>>   app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
> >>>>   app/test-pmd/config.c      | 128 ++++++++++++++++++++++------------------
> ---
> >> --
> >>>>   app/test-pmd/csumonly.c    |  22 ++++----
> >>>>   app/test-pmd/icmpecho.c    |   2 +-
> >>>>   app/test-pmd/ieee1588fwd.c |  18 +++----
> >>>> app/test-pmd/parameters.c
> >>>> |  50 +++++++++---------
> >>>>   app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++------------------
> ---
> >>>>   app/test-pmd/testpmd.h     |  28 +++++-----
> >>>>   app/test-pmd/txonly.c      |   2 +-
> >>>>   9 files changed, 237 insertions(+), 237 deletions(-)
> >>>> --
> >>>> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Ferruh Yigit]

On 3/23/2021 7:58 AM, Li, Xiaoyun wrote:
> 
> 
>> -----Original Message-----
>> From: oulijun <oulijun@huawei.com>
>> Sent: Tuesday, March 23, 2021 15:52
>> To: Tu, Lijuan <lijuan.tu@intel.com>; Andrew Rybchenko
>> <andrew.rybchenko@oktetlabs.ru>; Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit,
>> Ferruh <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>>
>>
>>
>> 在 2021/3/23 15:46, Tu, Lijuan 写道:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>> Sent: 2021年3月23日 15:25
>>>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Lijun Ou
>>>> <oulijun@huawei.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Tu,
>>>> Lijuan <lijuan.tu@intel.com>
>>>> Cc: dev@dpdk.org; linuxarm@openeuler.org
>>>> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in
>>>> testpmd
>>>>
>>>> On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
>>>>> Hi
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lijun Ou <oulijun@huawei.com>
>>>>>> Sent: Friday, March 5, 2021 18:22
>>>>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
>>>>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
>>>>>> linuxarm@openeuler.org
>>>>>> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
>>>>>>
>>>>>> From: Hongbo Zheng <zhenghongbo3@huawei.com>
>>>>>>
>>>>>> In testpmd, when we input "show config rxtx", we can see like this:
>>>>>>
>>>>>> 1: testpmd> show config rxtx
>>>>>> 2:   io packet forwarding packets/burst=32
>>>>>> 3:   nb forwarding cores=1 - nb forwarding ports=1
>>>>>> 4:   port 0: RX queue number: 1 Tx queue number: 1
>>>>>> 5:     Rx offloads=0x0 Tx offloads=0x10000
>>>>>> 6:     RX queue: 0
>>>>>> 7:       RX desc=1024 - RX free threshold=32
>>>>>> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
>>>>>> 9:       RX Offloads=0x0
>>>>>> 10:    TX queue: 0
>>>>>> 11:      TX desc=1024 - TX free threshold=928
>>>>>> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
>>>>>> 13:      TX offloads=0x10000 - TX RS bit threshold=32
>>>>>>
>>>>>> We can see RX/Rx/TX/Tx is mixed used. Also in other places in
>>>>>> testpmd, RX/Rx/TX/Tx is mixed used.
>>>>>>
>>>>>> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
>>>>>> unified use Rx/Tx.
>>>>>
>>>>> The commit log is too redundant. The following is enough to explain
>>>>> what this
>>>> patch does:
>>>>> RX/TX and Rx/Tx are mixed used in testpmd print and comments. This
>>>>> patch
>>>> unifies them as Rx/Tx.
>>>>>
>>>>> Except this, the patch looks good to me.
>>>>>
>>>>> But one big concern, this patch will break all of the CI tests
>>>>> because the DTS
>>>> scripts check if the results are the same as expected and this patch
>>>> change a lot of the print.
>>>>> So I think the DTS maintainer needs to be aware of this.
>>>>
>>>> I think test dpdk-testpmd output is a part of API. Of course, it is
>>>> not an API, but such cosmetic changes in output will be much more painful
>> than API changes.
>>>> Output parsers will simply stop to work. I think such changes should
>>>> go through the deprecation process.
>>>>
>>>> Of course, it would be useful to change comments and may be even
>>>> error log messages right now, but not commands output.
>>>>
>>>>>
>>>>> +Lijuan DTS maintainer
>>>
>>> It has big impact with CI system, most of test cases depended on the testpmd
>> output, if changed, our CI system will be broken, Is it really worth it ?
>>>
>> I think it's necessary to keep the style consistent and to constrain everyone to do
>> so in the future.However, if the DTS changes greatly, I think it is possible to
>> require the new print to be consistent and the historical part to remain
>> unchanged.Because the uniform change is also Xiaoyun's suggestion, we think
>> the opinion is reasonable, but we are not sure how much it will affect DTS.
> 
> I think we should drop this patch. But we'll keep consistent for future print when reviewing.
> What do you think?
> 

+1 to have consistency on the new code, and as the old code changed by time. 
Instead of big syntax cleanup.

As well as output parsing problem, this also can cause trouble on backporting 
patches for stable trees because of conflicts it will create.

>>>>>
>>>>> And please separate this patch with the other twos. Don't mix them
>>>>> in one
>>>> patchset. It's not for the same purpose.
>>>>>
>>>>>>
>>>>>> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
>>>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>>>> ---
>>>>>> V1->V2:
>>>>>> - fix all RX/TX
>>>>>> - rename patch title
>>>>>> ---
>>>>>>    app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
>>>>>>    app/test-pmd/config.c      | 128 ++++++++++++++++++++++------------------
>> ---
>>>> --
>>>>>>    app/test-pmd/csumonly.c    |  22 ++++----
>>>>>>    app/test-pmd/icmpecho.c    |   2 +-
>>>>>>    app/test-pmd/ieee1588fwd.c |  18 +++----
>>>>>> app/test-pmd/parameters.c
>>>>>> |  50 +++++++++---------
>>>>>>    app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++------------------
>> ---
>>>>>>    app/test-pmd/testpmd.h     |  28 +++++-----
>>>>>>    app/test-pmd/txonly.c      |   2 +-
>>>>>>    9 files changed, 237 insertions(+), 237 deletions(-)
>>>>>> --
>>>>>> 2.7.4

Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd

[Tu, Lijuan]

> -----Original Message-----
> From: oulijun <oulijun@huawei.com>
> Sent: 2021年3月23日 15:52
> To: Tu, Lijuan <lijuan.tu@intel.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit,
> Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; linuxarm@openeuler.org
> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> 
> 
> 
> 在 2021/3/23 15:46, Tu, Lijuan 写道:
> >
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >> Sent: 2021年3月23日 15:25
> >> To: Li, Xiaoyun <xiaoyun.li@intel.com>; Lijun Ou
> >> <oulijun@huawei.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Tu,
> >> Lijuan <lijuan.tu@intel.com>
> >> Cc: dev@dpdk.org; linuxarm@openeuler.org
> >> Subject: Re: [dpdk-dev] [PATCH 3/3] app/testpmd: use of Rx/Tx in
> >> testpmd
> >>
> >> On 3/23/21 6:17 AM, Li, Xiaoyun wrote:
> >>> Hi
> >>>
> >>>> -----Original Message-----
> >>>> From: Lijun Ou <oulijun@huawei.com>
> >>>> Sent: Friday, March 5, 2021 18:22
> >>>> To: Yigit, Ferruh <ferruh.yigit@intel.com>
> >>>> Cc: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org;
> >>>> linuxarm@openeuler.org
> >>>> Subject: [PATCH 3/3] app/testpmd: use of Rx/Tx in testpmd
> >>>>
> >>>> From: Hongbo Zheng <zhenghongbo3@huawei.com>
> >>>>
> >>>> In testpmd, when we input "show config rxtx", we can see like this:
> >>>>
> >>>> 1: testpmd> show config rxtx
> >>>> 2:   io packet forwarding packets/burst=32
> >>>> 3:   nb forwarding cores=1 - nb forwarding ports=1
> >>>> 4:   port 0: RX queue number: 1 Tx queue number: 1
> >>>> 5:     Rx offloads=0x0 Tx offloads=0x10000
> >>>> 6:     RX queue: 0
> >>>> 7:       RX desc=1024 - RX free threshold=32
> >>>> 8:       RX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >>>> 9:       RX Offloads=0x0
> >>>> 10:    TX queue: 0
> >>>> 11:      TX desc=1024 - TX free threshold=928
> >>>> 12:      TX threshold registers: pthresh=0 hthresh=0  wthresh=0
> >>>> 13:      TX offloads=0x10000 - TX RS bit threshold=32
> >>>>
> >>>> We can see RX/Rx/TX/Tx is mixed used. Also in other places in
> >>>> testpmd, RX/Rx/TX/Tx is mixed used.
> >>>>
> >>>> This patch fix the mixed use of RX/Rx/TX/Tx in testpmd by change to
> >>>> unified use Rx/Tx.
> >>>
> >>> The commit log is too redundant. The following is enough to explain
> >>> what this
> >> patch does:
> >>> RX/TX and Rx/Tx are mixed used in testpmd print and comments. This
> >>> patch
> >> unifies them as Rx/Tx.
> >>>
> >>> Except this, the patch looks good to me.
> >>>
> >>> But one big concern, this patch will break all of the CI tests
> >>> because the DTS
> >> scripts check if the results are the same as expected and this patch
> >> change a lot of the print.
> >>> So I think the DTS maintainer needs to be aware of this.
> >>
> >> I think test dpdk-testpmd output is a part of API. Of course, it is
> >> not an API, but such cosmetic changes in output will be much more painful
> than API changes.
> >> Output parsers will simply stop to work. I think such changes should
> >> go through the deprecation process.
> >>
> >> Of course, it would be useful to change comments and may be even
> >> error log messages right now, but not commands output.
> >>
> >>>
> >>> +Lijuan DTS maintainer
> >
> > It has big impact with CI system, most of test cases depended on the testpmd
> output, if changed, our CI system will be broken, Is it really worth it ?
> >
> I think it's necessary to keep the style consistent and to constrain everyone to do
> so in the future.However, if the DTS changes greatly, I think it is possible to
> require the new print to be consistent and the historical part to remain
> unchanged.Because the uniform change is also Xiaoyun's suggestion, we think
> the opinion is reasonable, but we are not sure how much it will affect DTS.

If that, I think it should go to DPDK tech board, shall we only unify testpmd or consider libraries and other applications.

> >>>
> >>> And please separate this patch with the other twos. Don't mix them
> >>> in one
> >> patchset. It's not for the same purpose.
> >>>
> >>>>
> >>>> Signed-off-by: Hongbo Zheng <zhenghongbo3@huawei.com>
> >>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >>>> ---
> >>>> V1->V2:
> >>>> - fix all RX/TX
> >>>> - rename patch title
> >>>> ---
> >>>>   app/test-pmd/cmdline.c     | 104 ++++++++++++++++++------------------
> >>>>   app/test-pmd/config.c      | 128 ++++++++++++++++++++++------------------
> ---
> >> --
> >>>>   app/test-pmd/csumonly.c    |  22 ++++----
> >>>>   app/test-pmd/icmpecho.c    |   2 +-
> >>>>   app/test-pmd/ieee1588fwd.c |  18 +++----
> >>>> app/test-pmd/parameters.c
> >>>> |  50 +++++++++---------
> >>>>   app/test-pmd/testpmd.c     | 120 +++++++++++++++++++++------------------
> ---
> >>>>   app/test-pmd/testpmd.h     |  28 +++++-----
> >>>>   app/test-pmd/txonly.c      |   2 +-
> >>>>   9 files changed, 237 insertions(+), 237 deletions(-)
> >>>> --
> >>>> 2.7.4

Re: [dpdk-dev] [PATCH 0/3] Fixes for testpmd

[Min Hu (Connor)]

Hi, Ferruh and all,
	have any comments about this set of patches?
	thanks.

在 2021/3/5 18:22, Lijun Ou 写道:
> This series add two test bug fixes and a print style.
> 
> Hongbo Zheng (1):
>    app/testpmd: use of Rx/Tx in testpmd
> 
> Huisong Li (2):
>    app/testpmd: fix forwarding configuration when DCB test
>    app/testpmd: remove forwarding config from parsing Rx and Tx
> 
>   app/test-pmd/cmdline.c     | 106 ++++++++++++++++----------------
>   app/test-pmd/config.c      | 147 +++++++++++++++++++++++++--------------------
>   app/test-pmd/csumonly.c    |  22 +++----
>   app/test-pmd/icmpecho.c    |   2 +-
>   app/test-pmd/ieee1588fwd.c |  18 +++---
>   app/test-pmd/parameters.c  |  50 +++++++--------
>   app/test-pmd/testpmd.c     | 132 ++++++++++++++++++++--------------------
>   app/test-pmd/testpmd.h     |  28 ++++-----
>   app/test-pmd/txonly.c      |   2 +-
>   9 files changed, 263 insertions(+), 244 deletions(-)
> 

[dpdk-dev] [PATCH V2 0/7] modifications about DCB forwarding configuration

[Huisong Li]

This patchset modifies some codes about DCB forwarding configuration.
It mainly includes:
- fix forward lcores number when dcb test
- remove dcb_test
- fix a segment fault when dcb test
- add check for support of reporting dcb info
- move position of verifying DCB test
- add forwarding config in start port
- remove redundant fwd streams initialization

---
V1->V2
 - remove patch "app/testpmd: use of Rx/Tx in testpmd"
 - fix patch title
 - remove dcb_test
 - add some new adjustments

---
Huisong Li (7):
  app/testpmd: fix forward lcores number when DCB test
  app/testpmd: fix DCB forwarding configuration
  app/testpmd: fix a segment fault when DCB test
  app/testpmd: add check for support of reporting DCB info
  app/testpmd: move position of verifying DCB test
  app/testpmd: add forwarding config in start port
  app/testpmd: remove redundant fwd streams initialization

 app/test-pmd/cmdline.c |  9 +++++++
 app/test-pmd/config.c  | 68 ++++++++++++++++++++++++++++++++++++++++++++++++--
 app/test-pmd/testpmd.c | 45 +++++++--------------------------
 app/test-pmd/testpmd.h |  1 -
 4 files changed, 84 insertions(+), 39 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test

[Huisong Li]

Currently, 'nb_fwd_lcores' value are both adjusted based on
'nb_fwd_streams' in rss/simple/icmp_echo_fwd_config_setup.
But the operation is missing in dcb_fwd_config_setup, which
may lead to a bad behavior in which multiple polling threads
operate on the same queue. In this case, the device sends and
receives packets, causing unexpected results. The procedure is
 as follows:
1/ run testpmd with "--rxq=8 --txq=8"
2/ port stop all
3/ set nbcore 8
4/ port config 0 dcb vt off 4 pfc on
5/ port config all rxq 16
6/ port config all txq 16
7/ port start all
8/ set fwd mac
9/ start

For the DCB forwarding test, each core is assigned to each
traffic class and each core is assigned a multi-stream.
Therefore, 'nb_fwd_lcores' value needs to be adjusted based
 on 'total_tc_num' in all forwarding ports.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index ccb9bd3..03ee40c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
 	}
 }
 
+static uint16_t
+get_fwd_port_total_tc_num(void)
+{
+	struct rte_eth_dcb_info dcb_info;
+	uint16_t total_tc_num = 0;
+	unsigned int i;
+
+	for (i = 0; i < nb_fwd_ports; i++) {
+		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
+		total_tc_num += dcb_info.nb_tcs;
+	}
+
+	return total_tc_num;
+}
+
 /**
  * For the DCB forwarding test, each core is assigned on each traffic class.
  *
@@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
 	lcoreid_t  lc_id;
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
+	uint16_t total_tc_num;
 	uint8_t tc = 0;
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
 	cur_fwd_config.nb_fwd_streams =
 		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
+	total_tc_num = get_fwd_port_total_tc_num();
+	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
+		cur_fwd_config.nb_fwd_lcores = total_tc_num;
 
 	/* reinitialize forwarding streams */
 	init_fwd_streams();
-- 
2.7.4

Re: [dpdk-dev] [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 15:32
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test
> 
> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
> rss/simple/icmp_echo_fwd_config_setup.
> But the operation is missing in dcb_fwd_config_setup, which may lead to a bad
> behavior in which multiple polling threads operate on the same queue. 

This patch is OK. But commit log is redundant and confusing.
The above is enough to explain what your patch is doing and can even be more simple.

>In this
> case, the device sends and receives packets, causing unexpected results. The
> procedure is  as follows:

I don't understand what you're saying here. The commands you're showing is 8 nbcores dealing with 16 queues. So it's one thread dealing with multiple queues which doesn't have issues at all.
Please remove the useless and confusing commands.

> 1/ run testpmd with "--rxq=8 --txq=8"
> 2/ port stop all
> 3/ set nbcore 8
> 4/ port config 0 dcb vt off 4 pfc on
> 5/ port config all rxq 16
> 6/ port config all txq 16
> 7/ port start all
> 8/ set fwd mac
> 9/ start
> 
> For the DCB forwarding test, each core is assigned to each traffic class and each
> core is assigned a multi-stream.
> Therefore, 'nb_fwd_lcores' value needs to be adjusted based  on 'total_tc_num'
> in all forwarding ports.

Please refer to the RSS fwd config fix patch to write your own commit log. Use simple and easy-understanding words to explain yourself.
Below is the reference of RSS.

commit 017d680a91fcf30da14a6d3a2f96d41f6dda3a0f
Author: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Date:   Mon Jun 27 23:35:19 2016 +0100

    app/testpmd: limit number of forwarding cores

    Number of forwarding cores must be equal or less than
    number of forwarding streams, otherwise two cores
    would try to use a same queue on a port, which is not allowed.

> 
> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/config.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> ccb9bd3..03ee40c 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
>  	}
>  }
> 
> +static uint16_t
> +get_fwd_port_total_tc_num(void)
> +{
> +	struct rte_eth_dcb_info dcb_info;
> +	uint16_t total_tc_num = 0;
> +	unsigned int i;
> +
> +	for (i = 0; i < nb_fwd_ports; i++) {
> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
> +		total_tc_num += dcb_info.nb_tcs;
> +	}
> +
> +	return total_tc_num;
> +}
> +
>  /**
>   * For the DCB forwarding test, each core is assigned on each traffic class.
>   *
> @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
>  	lcoreid_t  lc_id;
>  	uint16_t nb_rx_queue, nb_tx_queue;
>  	uint16_t i, j, k, sm_id = 0;
> +	uint16_t total_tc_num;
>  	uint8_t tc = 0;
> 
>  	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>  	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>  	cur_fwd_config.nb_fwd_streams =
>  		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
> +	total_tc_num = get_fwd_port_total_tc_num();
> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
> 
>  	/* reinitialize forwarding streams */
>  	init_fwd_streams();
> --
> 2.7.4

Re: [dpdk-dev] [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test

[Huisong Li]

在 2021/4/27 17:20, Li, Xiaoyun 写道:
>
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Tuesday, April 20, 2021 15:32
>> To: dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
>> linuxarm@openeuler.org; lihuisong@huawei.com
>> Subject: [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test
>>
>> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
>> rss/simple/icmp_echo_fwd_config_setup.
>> But the operation is missing in dcb_fwd_config_setup, which may lead to a bad
>> behavior in which multiple polling threads operate on the same queue.
> This patch is OK. But commit log is redundant and confusing.
> The above is enough to explain what your patch is doing and can even be more simple.
Sorry, I will fix it.
>> In this
>> case, the device sends and receives packets, causing unexpected results. The
>> procedure is  as follows:
> I don't understand what you're saying here. The commands you're showing is 8 nbcores dealing with 16 queues. So it's one thread dealing with multiple queues which doesn't have issues at all.
> Please remove the useless and confusing commands.

In the DCB test scenario, each TC is assigned a core, and one core can 
process multiple streams, that is, multiple queues.

In this scenario, if four TCs are enabled and the total number of Rx/Tx 
queues are set to 16, each TC is responsible for four queues. If we set 
8 core to start forwarding, and then 8 polling threads will be pulled 
up. Actually, the last four threads are redundant.

Before changing the number of polling cores, if the number of columns is 
greater than the number of TCs used later.  In the running process of 
the dcb_fwd_config_setup(), the data structure 'fwd_lcores[]' 
corresponding to the last four cores is not reinitialized. As a result, 
the last four threads would use the queue polled by the first four cores.

It's probably a bit of a twist.  In general, it is conditional that 
multiple cores operate on the same queue. That's why I posted the 
following steps.

In different forwarding mode, 'fwd_lcores[]' of all cores may need to be 
cleared before 'fwd_lcores[]' of each forwarding core is initialized. 
What do you think?

>> 1/ run testpmd with "--rxq=8 --txq=8"
>> 2/ port stop all
>> 3/ set nbcore 8
>> 4/ port config 0 dcb vt off 4 pfc on
>> 5/ port config all rxq 16
>> 6/ port config all txq 16
>> 7/ port start all
>> 8/ set fwd mac
>> 9/ start
>>
>> For the DCB forwarding test, each core is assigned to each traffic class and each
>> core is assigned a multi-stream.
>> Therefore, 'nb_fwd_lcores' value needs to be adjusted based  on 'total_tc_num'
>> in all forwarding ports.
> Please refer to the RSS fwd config fix patch to write your own commit log. Use simple and easy-understanding words to explain yourself.
> Below is the reference of RSS.
>
> commit 017d680a91fcf30da14a6d3a2f96d41f6dda3a0f
> Author: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Date:   Mon Jun 27 23:35:19 2016 +0100
>
>      app/testpmd: limit number of forwarding cores
>
>      Number of forwarding cores must be equal or less than
>      number of forwarding streams, otherwise two cores
>      would try to use a same queue on a port, which is not allowed.
>
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/config.c | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>> ccb9bd3..03ee40c 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
>>   	}
>>   }
>>
>> +static uint16_t
>> +get_fwd_port_total_tc_num(void)
>> +{
>> +	struct rte_eth_dcb_info dcb_info;
>> +	uint16_t total_tc_num = 0;
>> +	unsigned int i;
>> +
>> +	for (i = 0; i < nb_fwd_ports; i++) {
>> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
>> +		total_tc_num += dcb_info.nb_tcs;
>> +	}
>> +
>> +	return total_tc_num;
>> +}
>> +
>>   /**
>>    * For the DCB forwarding test, each core is assigned on each traffic class.
>>    *
>> @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
>>   	lcoreid_t  lc_id;
>>   	uint16_t nb_rx_queue, nb_tx_queue;
>>   	uint16_t i, j, k, sm_id = 0;
>> +	uint16_t total_tc_num;
>>   	uint8_t tc = 0;
>>
>>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>   	cur_fwd_config.nb_fwd_streams =
>>   		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
>> +	total_tc_num = get_fwd_port_total_tc_num();
>> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
>> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
>>
>>   	/* reinitialize forwarding streams */
>>   	init_fwd_streams();
>> --
>> 2.7.4
> .

Re: [dpdk-dev] [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 27, 2021 21:50
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: Re: [PATCH V2 1/7] app/testpmd: fix forward lcores number when DCB
> test
> 
> 
> 在 2021/4/27 17:20, Li, Xiaoyun 写道:
> >
> >> -----Original Message-----
> >> From: Huisong Li <lihuisong@huawei.com>
> >> Sent: Tuesday, April 20, 2021 15:32
> >> To: dev@dpdk.org
> >> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun
> >> <xiaoyun.li@intel.com>; linuxarm@openeuler.org; lihuisong@huawei.com
> >> Subject: [PATCH V2 1/7] app/testpmd: fix forward lcores number when
> >> DCB test
> >>
> >> Currently, 'nb_fwd_lcores' value are both adjusted based on
> >> 'nb_fwd_streams' in rss/simple/icmp_echo_fwd_config_setup.
> >> But the operation is missing in dcb_fwd_config_setup, which may lead
> >> to a bad behavior in which multiple polling threads operate on the same
> queue.
> > This patch is OK. But commit log is redundant and confusing.
> > The above is enough to explain what your patch is doing and can even be more
> simple.
> Sorry, I will fix it.
> >> In this
> >> case, the device sends and receives packets, causing unexpected
> >> results. The procedure is  as follows:
> > I don't understand what you're saying here. The commands you're showing is 8
> nbcores dealing with 16 queues. So it's one thread dealing with multiple queues
> which doesn't have issues at all.
> > Please remove the useless and confusing commands.
> 
> In the DCB test scenario, each TC is assigned a core, and one core can process
> multiple streams, that is, multiple queues.
> 
> In this scenario, if four TCs are enabled and the total number of Rx/Tx queues
> are set to 16, each TC is responsible for four queues. If we set
> 8 core to start forwarding, and then 8 polling threads will be pulled up. Actually,
> the last four threads are redundant.
> 
> Before changing the number of polling cores, if the number of columns is
> greater than the number of TCs used later.  In the running process of the
> dcb_fwd_config_setup(), the data structure 'fwd_lcores[]'
> corresponding to the last four cores is not reinitialized. As a result, the last four
> threads would use the queue polled by the first four cores.
> 
> It's probably a bit of a twist.  In general, it is conditional that multiple cores
> operate on the same queue. That's why I posted the following steps.
> 
> In different forwarding mode, 'fwd_lcores[]' of all cores may need to be cleared
> before 'fwd_lcores[]' of each forwarding core is initialized.
> What do you think?

Understood. But then you actually don't need to set rxq/txq to 16. Even if it's 8 queues, each tc is responsible for 2 queues. 8 cores will still cause that issue.
Changing queue number will be confusing. Like I didn't read it very carefully then I misunderstood what you were trying to explain here.
The example doesn't make your commit log clear but more confusing.

And the code is actually quite straightforward. I think the easy explanation is better.

But anyway, if you still want to keep the example, remove setting queue number again.

> 
> >> 1/ run testpmd with "--rxq=8 --txq=8"
> >> 2/ port stop all
> >> 3/ set nbcore 8
> >> 4/ port config 0 dcb vt off 4 pfc on
> >> 5/ port config all rxq 16
> >> 6/ port config all txq 16
> >> 7/ port start all
> >> 8/ set fwd mac
> >> 9/ start
> >>
> >> For the DCB forwarding test, each core is assigned to each traffic
> >> class and each core is assigned a multi-stream.
> >> Therefore, 'nb_fwd_lcores' value needs to be adjusted based  on
> 'total_tc_num'
> >> in all forwarding ports.
> > Please refer to the RSS fwd config fix patch to write your own commit log. Use
> simple and easy-understanding words to explain yourself.
> > Below is the reference of RSS.
> >
> > commit 017d680a91fcf30da14a6d3a2f96d41f6dda3a0f
> > Author: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> > Date:   Mon Jun 27 23:35:19 2016 +0100
> >
> >      app/testpmd: limit number of forwarding cores
> >
> >      Number of forwarding cores must be equal or less than
> >      number of forwarding streams, otherwise two cores
> >      would try to use a same queue on a port, which is not allowed.
> >
> >> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> >> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >> ---
> >>   app/test-pmd/config.c | 19 +++++++++++++++++++
> >>   1 file changed, 19 insertions(+)
> >>
> >> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> >> ccb9bd3..03ee40c 100644
> >> --- a/app/test-pmd/config.c
> >> +++ b/app/test-pmd/config.c
> >> @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
> >>   	}
> >>   }
> >>
> >> +static uint16_t
> >> +get_fwd_port_total_tc_num(void)
> >> +{
> >> +	struct rte_eth_dcb_info dcb_info;
> >> +	uint16_t total_tc_num = 0;
> >> +	unsigned int i;
> >> +
> >> +	for (i = 0; i < nb_fwd_ports; i++) {
> >> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
> >> +		total_tc_num += dcb_info.nb_tcs;
> >> +	}
> >> +
> >> +	return total_tc_num;
> >> +}
> >> +
> >>   /**
> >>    * For the DCB forwarding test, each core is assigned on each traffic class.
> >>    *
> >> @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
> >>   	lcoreid_t  lc_id;
> >>   	uint16_t nb_rx_queue, nb_tx_queue;
> >>   	uint16_t i, j, k, sm_id = 0;
> >> +	uint16_t total_tc_num;
> >>   	uint8_t tc = 0;
> >>
> >>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
> >>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
> >>   	cur_fwd_config.nb_fwd_streams =
> >>   		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
> >> +	total_tc_num = get_fwd_port_total_tc_num();
> >> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
> >> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
> >>
> >>   	/* reinitialize forwarding streams */
> >>   	init_fwd_streams();
> >> --
> >> 2.7.4
> > .

[dpdk-dev] [PATCH V2 2/7] app/testpmd: fix DCB forwarding configuration

[Huisong Li]

After DCB mode is configured, the operations of port stop and port start
change the value of the global variable "dcb_test", As a result, the
forwarding configuration from DCB to RSS mode, namely,
“dcb_fwd_config_setup()” to "rss_fwd_config_setup()".

Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether
 the port is configured with DCB. And it is sufficient to have 'dcb_config'
as a global variable to control the DCB test status. So this patch deletes
the "dcb_test".

In addition, the 'dcb_config' is first set to 1 first in
init_port_dcb_config(), but the function may fail.
 So it should be moved to the end.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 18 ++++--------------
 app/test-pmd/testpmd.h |  1 -
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index d4be23f..a076b1d 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE; /**< Size of mbuf mempool cache. */
 /* current configuration is in DCB or not,0 means it is not in DCB mode */
 uint8_t dcb_config = 0;
 
-/* Whether the dcb is in testing status */
-uint8_t dcb_test = 0;
-
 /*
  * Configurable number of RX/TX queues.
  */
@@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first)
 		return;
 	}
 
-
-	if(dcb_test) {
+	if (dcb_config) {
 		for (i = 0; i < nb_fwd_ports; i++) {
 			pt_id = fwd_ports_ids[i];
 			port = &ports[pt_id];
@@ -2476,8 +2472,6 @@ start_port(portid_t pid)
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return 0;
 
-	if(dcb_config)
-		dcb_test = 1;
 	RTE_ETH_FOREACH_DEV(pi) {
 		if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
 			continue;
@@ -2717,11 +2711,6 @@ stop_port(portid_t pid)
 	portid_t peer_pl[RTE_MAX_ETHPORTS];
 	int peer_pi;
 
-	if (dcb_test) {
-		dcb_test = 0;
-		dcb_config = 0;
-	}
-
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return;
 
@@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid,
 	rte_port = &ports[pid];
 
 	memset(&port_conf, 0, sizeof(struct rte_eth_conf));
-	/* Enter DCB configuration status */
-	dcb_config = 1;
 
 	port_conf.rxmode = rte_port->dev_conf.rxmode;
 	port_conf.txmode = rte_port->dev_conf.txmode;
@@ -3694,6 +3681,9 @@ init_port_dcb_config(portid_t pid,
 
 	rte_port->dcb_flag = 1;
 
+	/* Enter DCB configuration status */
+	dcb_config = 1;
+
 	return 0;
 }
 
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 9530ec5..432c66d 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads;
 extern uint64_t noisy_lkup_num_reads_writes;
 
 extern uint8_t dcb_config;
-extern uint8_t dcb_test;
 
 extern uint32_t mbuf_data_size_n;
 extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT];
-- 
2.7.4

[dpdk-dev] [PATCH V2 3/7] app/testpmd: fix a segment fault when DCB test

[Huisong Li]

After DCB mode is configured, if we decrease the number of RX and TX
queues, fwd_config_setup() will be called to setup the DCB forwarding
configuration. And forwarding streams are updated based on new queue
numbers in fwd_config_setup(), but the mapping between the TC and
queues obtained by rte_eth_dev_get_dcb_info() is still old queue
numbers (old queue numbers are greater than new queue numbers).
In this case, the segment fault happens. So rte_eth_dev_configure()
should be called again to update the mapping between the TC and
queues before rte_eth_dev_get_dcb_info().

Like:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
port stop all
port config all rxq 8
port config all txq 8

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 03ee40c..18b197b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
 	uint16_t total_tc_num;
+	struct rte_port *port;
 	uint8_t tc = 0;
+	portid_t pid;
+	int ret;
+
+	/*
+	 * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
+	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED, dev_configure
+	 * cannot be called.
+	 *
+	 * re-configure the device after changing queue numbers of stopped
+	 * ports, so that the updated mapping between tc and queue can be
+	 * obtained.
+	 */
+	for (pid = 0; pid < nb_fwd_ports; pid++) {
+		if (port_is_started(pid) == 1)
+			continue;
+
+		port = &ports[pid];
+		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
+					    &port->dev_conf);
+		if (ret < 0) {
+			printf("Failed to re-configure port %d, ret = %d.\n",
+				pid, ret);
+			return;
+		}
+	}
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
-- 
2.7.4

[dpdk-dev] [PATCH V2 4/7] app/testpmd: add check for support of reporting DCB info

[Huisong Li]

Currently, '.get_dcb_info' must be supported for the port doing DCB test,
or all information in 'rte_eth_dcb_info' are zero. It should be prevented
when user run cmd "port config 0 dcb vt off 4 pfc off".

This patch adds the check for support of reporting dcb info.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/cmdline.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d282c7c..6f4f642 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3170,6 +3170,7 @@ cmd_config_dcb_parsed(void *parsed_result,
                         __rte_unused void *data)
 {
 	struct cmd_config_dcb *res = parsed_result;
+	struct rte_eth_dcb_info dcb_info;
 	portid_t port_id = res->port_id;
 	struct rte_port *port;
 	uint8_t pfc_en;
@@ -3192,6 +3193,14 @@ cmd_config_dcb_parsed(void *parsed_result,
 		printf("nb_cores shouldn't be less than number of TCs.\n");
 		return;
 	}
+
+	/* Check whether the port supports the report of DCB info. */
+	ret = rte_eth_dev_get_dcb_info(port_id, &dcb_info);
+	if (ret == -ENOTSUP) {
+		printf("Network port must support rte_eth_dev_get_dcb_info API, or cann't does dcb test.\n");
+		return;
+	}
+
 	if (!strncmp(res->pfc_en, "on", 2))
 		pfc_en = 1;
 	else
-- 
2.7.4

[dpdk-dev] [PATCH V2 5/7] app/testpmd: move position of verifying DCB test

[Huisong Li]

Currently, the check for doing DCB test is assigned to
start_packet_forwarding(), which will be called when
run "start" cmd. But fwd_config_setup() is used in many
scenarios, such as, "port config all rxq".

This patch moves the check from start_packet_forwarding()
to fwd_config_setup().

Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c  | 23 +++++++++++++++++++++--
 app/test-pmd/testpmd.c | 19 -------------------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 18b197b..66974f8 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3152,6 +3152,10 @@ icmp_echo_config_setup(void)
 void
 fwd_config_setup(void)
 {
+	struct rte_port *port;
+	portid_t pt_id;
+	unsigned int i;
+
 	cur_fwd_config.fwd_eng = cur_fwd_eng;
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "icmpecho") == 0) {
 		icmp_echo_config_setup();
@@ -3159,9 +3163,24 @@ fwd_config_setup(void)
 	}
 
 	if ((nb_rxq > 1) && (nb_txq > 1)){
-		if (dcb_config)
+		if (dcb_config) {
+			for (i = 0; i < nb_fwd_ports; i++) {
+				pt_id = fwd_ports_ids[i];
+				port = &ports[pt_id];
+				if (!port->dcb_flag) {
+					printf("In DCB mode, all forwarding ports must "
+						"be configured in this mode.\n");
+					return;
+				}
+			}
+			if (nb_fwd_lcores == 1) {
+				printf("In DCB mode,the nb forwarding cores "
+					"should be larger than 1.\n");
+				return;
+			}
+
 			dcb_fwd_config_setup();
-		else
+		} else
 			rss_fwd_config_setup();
 	}
 	else
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index a076b1d..abcbdaa 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2138,9 +2138,7 @@ start_packet_forwarding(int with_tx_first)
 {
 	port_fwd_begin_t port_fwd_begin;
 	port_fwd_end_t  port_fwd_end;
-	struct rte_port *port;
 	unsigned int i;
-	portid_t   pt_id;
 
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "rxonly") == 0 && !nb_rxq)
 		rte_exit(EXIT_FAILURE, "rxq are 0, cannot use rxonly fwd mode\n");
@@ -2163,23 +2161,6 @@ start_packet_forwarding(int with_tx_first)
 		printf("Packet forwarding already started\n");
 		return;
 	}
-
-	if (dcb_config) {
-		for (i = 0; i < nb_fwd_ports; i++) {
-			pt_id = fwd_ports_ids[i];
-			port = &ports[pt_id];
-			if (!port->dcb_flag) {
-				printf("In DCB mode, all forwarding ports must "
-                                       "be configured in this mode.\n");
-				return;
-			}
-		}
-		if (nb_fwd_lcores == 1) {
-			printf("In DCB mode,the nb forwarding cores "
-                               "should be larger than 1.\n");
-			return;
-		}
-	}
 	test_done = 0;
 
 	fwd_config_setup();
-- 
2.7.4

[dpdk-dev] [PATCH V2 6/7] app/testpmd: add forwarding config in start port

[Huisong Li]

Most operations in testpmd that need to update the forwarding streams
in testpmd call fwd_config_setup(). In some scenarios, eg, dev_configure
is called again, the forwarding streams may not be updated. As a result,
the actual forwarding streams cannot be queried by "show config fwd" cmd.

The procedure is as follows:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
show config fwd

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index abcbdaa..f8052b6 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2678,6 +2678,12 @@ start_port(portid_t pid)
 			}
 		}
 	}
+	/*
+	 * In some scenarios, eg, dev_configure is called again, the forwarding
+	 * streams may not be updated. As a result, the actual forwarding
+	 * streams cannot be queried by "show config fwd" command.
+	 */
+	fwd_config_setup();
 
 	printf("Done\n");
 	return 0;
-- 
2.7.4

[dpdk-dev] [PATCH V2 7/7] app/testpmd: remove redundant fwd streams initialization

[Huisong Li]

The fwd_config_setup() is called after init_fwd_streams().
The fwd_config_setup() will reinitialize forwarding streams.
This patch removes init_fwd_streams() from init_config().

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index f8052b6..79b5d97 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1576,10 +1576,6 @@ init_config(void)
 		fwd_lcores[lc_id]->gso_ctx.flag = 0;
 	}
 
-	/* Configuration of packet forwarding streams. */
-	if (init_fwd_streams() < 0)
-		rte_exit(EXIT_FAILURE, "FAIL from init_fwd_streams()\n");
-
 	fwd_config_setup();
 
 	/* create a gro context for each lcore */
-- 
2.7.4

Re: [dpdk-dev] [PATCH 0/3] Fixes for testpmd

[Huisong Li]

Hi, Ferruh and Xiaoyun,

Lijun has other arrangements, I will be responsible for closing this 
patchset.
V2 has been sent. Please review. Thanks!

在 2021/3/5 18:22, Lijun Ou 写道:
> This series add two test bug fixes and a print style.
>
> Hongbo Zheng (1):
>    app/testpmd: use of Rx/Tx in testpmd
>
> Huisong Li (2):
>    app/testpmd: fix forwarding configuration when DCB test
>    app/testpmd: remove forwarding config from parsing Rx and Tx
>
>   app/test-pmd/cmdline.c     | 106 ++++++++++++++++----------------
>   app/test-pmd/config.c      | 147 +++++++++++++++++++++++++--------------------
>   app/test-pmd/csumonly.c    |  22 +++----
>   app/test-pmd/icmpecho.c    |   2 +-
>   app/test-pmd/ieee1588fwd.c |  18 +++---
>   app/test-pmd/parameters.c  |  50 +++++++--------
>   app/test-pmd/testpmd.c     | 132 ++++++++++++++++++++--------------------
>   app/test-pmd/testpmd.h     |  28 ++++-----
>   app/test-pmd/txonly.c      |   2 +-
>   9 files changed, 263 insertions(+), 244 deletions(-)
>

[dpdk-dev] [PATCH V3 0/7] modifications about DCB forwarding configuration

[Huisong Li]

This patchset modifies some codes about DCB forwarding configuration.
It mainly includes:
- fix forward lcores number when dcb test
- remove dcb_test
- fix a segment fault when dcb test
- add check for support of reporting dcb info
- move position of verifying DCB test
- add forwarding config in start port
- remove redundant fwd streams initialization

---
V2->V3
 - fix abnormal print information

V1->V2
 - remove patch "app/testpmd: use of Rx/Tx in testpmd"
 - fix patch title
 - remove dcb_test
 - add some new adjustments

---

Huisong Li (7):
  app/testpmd: fix forward lcores number when DCB test
  app/testpmd: fix DCB forwarding configuration
  app/testpmd: fix a segment fault when DCB test
  app/testpmd: add check for support of reporting DCB info
  app/testpmd: move position of verifying DCB test
  app/testpmd: add forwarding config in start port
  app/testpmd: remove redundant fwd streams initialization

 app/test-pmd/cmdline.c |  9 +++++++
 app/test-pmd/config.c  | 68 +++++++++++++++++++++++++++++++++++++++++--
 app/test-pmd/testpmd.c | 45 +++++++--------------------------
 app/test-pmd/testpmd.h |  1 -
 4 files changed, 84 insertions(+), 39 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH V3 1/7] app/testpmd: fix forward lcores number when DCB test

[Huisong Li]

Currently, 'nb_fwd_lcores' value are both adjusted based on
'nb_fwd_streams' in rss/simple/icmp_echo_fwd_config_setup.
But the operation is missing in dcb_fwd_config_setup, which
may lead to a bad behavior in which multiple polling threads
operate on the same queue. In this case, the device sends and
receives packets, causing unexpected results. The procedure is
 as follows:
1/ run testpmd with "--rxq=8 --txq=8"
2/ port stop all
3/ set nbcore 8
4/ port config 0 dcb vt off 4 pfc on
5/ port config all rxq 16
6/ port config all txq 16
7/ port start all
8/ set fwd mac
9/ start

For the DCB forwarding test, each core is assigned to each
traffic class and each core is assigned a multi-stream.
Therefore, 'nb_fwd_lcores' value needs to be adjusted based
 on 'total_tc_num' in all forwarding ports.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index ccb9bd3..03ee40c 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
 	}
 }
 
+static uint16_t
+get_fwd_port_total_tc_num(void)
+{
+	struct rte_eth_dcb_info dcb_info;
+	uint16_t total_tc_num = 0;
+	unsigned int i;
+
+	for (i = 0; i < nb_fwd_ports; i++) {
+		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
+		total_tc_num += dcb_info.nb_tcs;
+	}
+
+	return total_tc_num;
+}
+
 /**
  * For the DCB forwarding test, each core is assigned on each traffic class.
  *
@@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
 	lcoreid_t  lc_id;
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
+	uint16_t total_tc_num;
 	uint8_t tc = 0;
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
 	cur_fwd_config.nb_fwd_streams =
 		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
+	total_tc_num = get_fwd_port_total_tc_num();
+	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
+		cur_fwd_config.nb_fwd_lcores = total_tc_num;
 
 	/* reinitialize forwarding streams */
 	init_fwd_streams();
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 1/7] app/testpmd: fix forward lcores number when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 1/7] app/testpmd: fix forward lcores number when DCB test
> 
> Currently, 'nb_fwd_lcores' value are both adjusted based on 'nb_fwd_streams' in
> rss/simple/icmp_echo_fwd_config_setup.
> But the operation is missing in dcb_fwd_config_setup, which may lead to a bad
> behavior in which multiple polling threads operate on the same queue. In this
> case, the device sends and receives packets, causing unexpected results. The
> procedure is  as follows:
> 1/ run testpmd with "--rxq=8 --txq=8"
> 2/ port stop all
> 3/ set nbcore 8
> 4/ port config 0 dcb vt off 4 pfc on
> 5/ port config all rxq 16
> 6/ port config all txq 16
> 7/ port start all
> 8/ set fwd mac
> 9/ start
> 
Same as v2 comment.
Please check that.

> For the DCB forwarding test, each core is assigned to each traffic class and each
> core is assigned a multi-stream.
> Therefore, 'nb_fwd_lcores' value needs to be adjusted based  on 'total_tc_num'
> in all forwarding ports.
> 
> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/config.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> ccb9bd3..03ee40c 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -2961,6 +2961,21 @@ rss_fwd_config_setup(void)
>  	}
>  }
> 
> +static uint16_t
> +get_fwd_port_total_tc_num(void)
> +{
> +	struct rte_eth_dcb_info dcb_info;
> +	uint16_t total_tc_num = 0;
> +	unsigned int i;
> +
> +	for (i = 0; i < nb_fwd_ports; i++) {
> +		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
> +		total_tc_num += dcb_info.nb_tcs;
> +	}
> +
> +	return total_tc_num;
> +}
> +
>  /**
>   * For the DCB forwarding test, each core is assigned on each traffic class.
>   *
> @@ -2980,12 +2995,16 @@ dcb_fwd_config_setup(void)
>  	lcoreid_t  lc_id;
>  	uint16_t nb_rx_queue, nb_tx_queue;
>  	uint16_t i, j, k, sm_id = 0;
> +	uint16_t total_tc_num;
>  	uint8_t tc = 0;
> 
>  	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>  	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>  	cur_fwd_config.nb_fwd_streams =
>  		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
> +	total_tc_num = get_fwd_port_total_tc_num();
> +	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
> +		cur_fwd_config.nb_fwd_lcores = total_tc_num;
> 
>  	/* reinitialize forwarding streams */
>  	init_fwd_streams();
> --
> 2.7.4

[dpdk-dev] [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration

[Huisong Li]

After DCB mode is configured, the operations of port stop and port start
change the value of the global variable "dcb_test", As a result, the
forwarding configuration from DCB to RSS mode, namely,
“dcb_fwd_config_setup()” to "rss_fwd_config_setup()".

Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether
 the port is configured with DCB. And it is sufficient to have 'dcb_config'
as a global variable to control the DCB test status. So this patch deletes
the "dcb_test".

In addition, the 'dcb_config' is first set to 1 first in
init_port_dcb_config(), but the function may fail.
 So it should be moved to the end.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 18 ++++--------------
 app/test-pmd/testpmd.h |  1 -
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index d4be23f..a076b1d 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE; /**< Size of mbuf mempool cache. */
 /* current configuration is in DCB or not,0 means it is not in DCB mode */
 uint8_t dcb_config = 0;
 
-/* Whether the dcb is in testing status */
-uint8_t dcb_test = 0;
-
 /*
  * Configurable number of RX/TX queues.
  */
@@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first)
 		return;
 	}
 
-
-	if(dcb_test) {
+	if (dcb_config) {
 		for (i = 0; i < nb_fwd_ports; i++) {
 			pt_id = fwd_ports_ids[i];
 			port = &ports[pt_id];
@@ -2476,8 +2472,6 @@ start_port(portid_t pid)
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return 0;
 
-	if(dcb_config)
-		dcb_test = 1;
 	RTE_ETH_FOREACH_DEV(pi) {
 		if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
 			continue;
@@ -2717,11 +2711,6 @@ stop_port(portid_t pid)
 	portid_t peer_pl[RTE_MAX_ETHPORTS];
 	int peer_pi;
 
-	if (dcb_test) {
-		dcb_test = 0;
-		dcb_config = 0;
-	}
-
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return;
 
@@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid,
 	rte_port = &ports[pid];
 
 	memset(&port_conf, 0, sizeof(struct rte_eth_conf));
-	/* Enter DCB configuration status */
-	dcb_config = 1;
 
 	port_conf.rxmode = rte_port->dev_conf.rxmode;
 	port_conf.txmode = rte_port->dev_conf.txmode;
@@ -3694,6 +3681,9 @@ init_port_dcb_config(portid_t pid,
 
 	rte_port->dcb_flag = 1;
 
+	/* Enter DCB configuration status */
+	dcb_config = 1;
+
 	return 0;
 }
 
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 9530ec5..432c66d 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads;
 extern uint64_t noisy_lkup_num_reads_writes;
 
 extern uint8_t dcb_config;
-extern uint8_t dcb_test;
 
 extern uint32_t mbuf_data_size_n;
 extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT];
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration
> 
> After DCB mode is configured, the operations of port stop and port start change
> the value of the global variable "dcb_test", As a result, the forwarding
> configuration from DCB to RSS mode, namely, “dcb_fwd_config_setup()” to
> "rss_fwd_config_setup()".
> 
> Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether  the port is
> configured with DCB. And it is sufficient to have 'dcb_config'
> as a global variable to control the DCB test status. So this patch deletes the
> "dcb_test".
> 
> In addition, the 'dcb_config' is first set to 1 first in init_port_dcb_config(), but
> the function may fail.
>  So it should be moved to the end.

Change this to the following will be better:
In addition, setting 'dcb_config' at the end of init_port_dcb_config() in case that ports fail to enter DCB mode.

> 
> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/testpmd.c | 18 ++++--------------  app/test-pmd/testpmd.h |  1 -
>  2 files changed, 4 insertions(+), 15 deletions(-)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> d4be23f..a076b1d 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE;
> /**< Size of mbuf mempool cache. */
>  /* current configuration is in DCB or not,0 means it is not in DCB mode */
> uint8_t dcb_config = 0;
> 
> -/* Whether the dcb is in testing status */ -uint8_t dcb_test = 0;
> -
>  /*
>   * Configurable number of RX/TX queues.
>   */
> @@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first)
>  		return;
>  	}
> 
> -
> -	if(dcb_test) {
> +	if (dcb_config) {
>  		for (i = 0; i < nb_fwd_ports; i++) {
>  			pt_id = fwd_ports_ids[i];
>  			port = &ports[pt_id];
> @@ -2476,8 +2472,6 @@ start_port(portid_t pid)
>  	if (port_id_is_invalid(pid, ENABLED_WARN))
>  		return 0;
> 
> -	if(dcb_config)
> -		dcb_test = 1;
>  	RTE_ETH_FOREACH_DEV(pi) {
>  		if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
>  			continue;
> @@ -2717,11 +2711,6 @@ stop_port(portid_t pid)
>  	portid_t peer_pl[RTE_MAX_ETHPORTS];
>  	int peer_pi;
> 
> -	if (dcb_test) {
> -		dcb_test = 0;
> -		dcb_config = 0;
> -	}
> -
>  	if (port_id_is_invalid(pid, ENABLED_WARN))
>  		return;
> 
> @@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid,
>  	rte_port = &ports[pid];
> 
>  	memset(&port_conf, 0, sizeof(struct rte_eth_conf));
> -	/* Enter DCB configuration status */
> -	dcb_config = 1;
> 
>  	port_conf.rxmode = rte_port->dev_conf.rxmode;
>  	port_conf.txmode = rte_port->dev_conf.txmode; @@ -3694,6 +3681,9
> @@ init_port_dcb_config(portid_t pid,
> 
>  	rte_port->dcb_flag = 1;
> 
> +	/* Enter DCB configuration status */
> +	dcb_config = 1;
> +
>  	return 0;
>  }
> 
> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> 9530ec5..432c66d 100644
> --- a/app/test-pmd/testpmd.h
> +++ b/app/test-pmd/testpmd.h
> @@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads;  extern uint64_t
> noisy_lkup_num_reads_writes;
> 
>  extern uint8_t dcb_config;
> -extern uint8_t dcb_test;
> 
>  extern uint32_t mbuf_data_size_n;
>  extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT];
> --
> 2.7.4

Re: [dpdk-dev] [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration

[Huisong Li]

在 2021/4/27 18:59, Li, Xiaoyun 写道:
>
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Tuesday, April 20, 2021 17:01
>> To: dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
>> linuxarm@openeuler.org; lihuisong@huawei.com
>> Subject: [PATCH V3 2/7] app/testpmd: fix DCB forwarding configuration
>>
>> After DCB mode is configured, the operations of port stop and port start change
>> the value of the global variable "dcb_test", As a result, the forwarding
>> configuration from DCB to RSS mode, namely, “dcb_fwd_config_setup()” to
>> "rss_fwd_config_setup()".
>>
>> Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether  the port is
>> configured with DCB. And it is sufficient to have 'dcb_config'
>> as a global variable to control the DCB test status. So this patch deletes the
>> "dcb_test".
>>
>> In addition, the 'dcb_config' is first set to 1 first in init_port_dcb_config(), but
>> the function may fail.
>>   So it should be moved to the end.
> Change this to the following will be better:
> In addition, setting 'dcb_config' at the end of init_port_dcb_config() in case that ports fail to enter DCB mode.
ok
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
>> Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/testpmd.c | 18 ++++--------------  app/test-pmd/testpmd.h |  1 -
>>   2 files changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>> d4be23f..a076b1d 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE;
>> /**< Size of mbuf mempool cache. */
>>   /* current configuration is in DCB or not,0 means it is not in DCB mode */
>> uint8_t dcb_config = 0;
>>
>> -/* Whether the dcb is in testing status */ -uint8_t dcb_test = 0;
>> -
>>   /*
>>    * Configurable number of RX/TX queues.
>>    */
>> @@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first)
>>   		return;
>>   	}
>>
>> -
>> -	if(dcb_test) {
>> +	if (dcb_config) {
>>   		for (i = 0; i < nb_fwd_ports; i++) {
>>   			pt_id = fwd_ports_ids[i];
>>   			port = &ports[pt_id];
>> @@ -2476,8 +2472,6 @@ start_port(portid_t pid)
>>   	if (port_id_is_invalid(pid, ENABLED_WARN))
>>   		return 0;
>>
>> -	if(dcb_config)
>> -		dcb_test = 1;
>>   	RTE_ETH_FOREACH_DEV(pi) {
>>   		if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
>>   			continue;
>> @@ -2717,11 +2711,6 @@ stop_port(portid_t pid)
>>   	portid_t peer_pl[RTE_MAX_ETHPORTS];
>>   	int peer_pi;
>>
>> -	if (dcb_test) {
>> -		dcb_test = 0;
>> -		dcb_config = 0;
>> -	}
>> -
>>   	if (port_id_is_invalid(pid, ENABLED_WARN))
>>   		return;
>>
>> @@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid,
>>   	rte_port = &ports[pid];
>>
>>   	memset(&port_conf, 0, sizeof(struct rte_eth_conf));
>> -	/* Enter DCB configuration status */
>> -	dcb_config = 1;
>>
>>   	port_conf.rxmode = rte_port->dev_conf.rxmode;
>>   	port_conf.txmode = rte_port->dev_conf.txmode; @@ -3694,6 +3681,9
>> @@ init_port_dcb_config(portid_t pid,
>>
>>   	rte_port->dcb_flag = 1;
>>
>> +	/* Enter DCB configuration status */
>> +	dcb_config = 1;
>> +
>>   	return 0;
>>   }
>>
>> diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
>> 9530ec5..432c66d 100644
>> --- a/app/test-pmd/testpmd.h
>> +++ b/app/test-pmd/testpmd.h
>> @@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads;  extern uint64_t
>> noisy_lkup_num_reads_writes;
>>
>>   extern uint8_t dcb_config;
>> -extern uint8_t dcb_test;
>>
>>   extern uint32_t mbuf_data_size_n;
>>   extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT];
>> --
>> 2.7.4

[dpdk-dev] [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test

[Huisong Li]

After DCB mode is configured, if we decrease the number of RX and TX
queues, fwd_config_setup() will be called to setup the DCB forwarding
configuration. And forwarding streams are updated based on new queue
numbers in fwd_config_setup(), but the mapping between the TC and
queues obtained by rte_eth_dev_get_dcb_info() is still old queue
numbers (old queue numbers are greater than new queue numbers).
In this case, the segment fault happens. So rte_eth_dev_configure()
should be called again to update the mapping between the TC and
queues before rte_eth_dev_get_dcb_info().

Like:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
port stop all
port config all rxq 8
port config all txq 8

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 03ee40c..18b197b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
 	uint16_t total_tc_num;
+	struct rte_port *port;
 	uint8_t tc = 0;
+	portid_t pid;
+	int ret;
+
+	/*
+	 * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
+	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED, dev_configure
+	 * cannot be called.
+	 *
+	 * re-configure the device after changing queue numbers of stopped
+	 * ports, so that the updated mapping between tc and queue can be
+	 * obtained.
+	 */
+	for (pid = 0; pid < nb_fwd_ports; pid++) {
+		if (port_is_started(pid) == 1)
+			continue;
+
+		port = &ports[pid];
+		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
+					    &port->dev_conf);
+		if (ret < 0) {
+			printf("Failed to re-configure port %d, ret = %d.\n",
+				pid, ret);
+			return;
+		}
+	}
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test
> 
> After DCB mode is configured, if we decrease the number of RX and TX queues,
> fwd_config_setup() will be called to setup the DCB forwarding configuration.
> And forwarding streams are updated based on new queue numbers in
> fwd_config_setup(), but the mapping between the TC and queues obtained by
> rte_eth_dev_get_dcb_info() is still old queue numbers (old queue numbers are
> greater than new queue numbers).
> In this case, the segment fault happens. So rte_eth_dev_configure() should be
> called again to update the mapping between the TC and queues before
> rte_eth_dev_get_dcb_info().
> 
> Like:
> set nbcore 4
> port stop all
> port config 0 dcb vt off 4 pfc on
> port start all
> port stop all
> port config all rxq 8
> port config all txq 8
> 
> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> 03ee40c..18b197b 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
>  	uint16_t nb_rx_queue, nb_tx_queue;
>  	uint16_t i, j, k, sm_id = 0;
>  	uint16_t total_tc_num;
> +	struct rte_port *port;
>  	uint8_t tc = 0;
> +	portid_t pid;
> +	int ret;
> +
> +	/*
> +	 * The fwd_config_setup() is called when the port is
> RTE_PORT_STARTED

When the port is RTE_PORT_STARTED or RTE_PORT_STARTED? Missing an 'or' here.
Maybe something like the following will be better? (just a reference, you can put it in a better way)
/*
  * Re-configure ports to get updated mapping between tc and queue in case the queue number of the port is changed.
  * Skip for started ports since configuring queue number needs to stop ports first.
  */

> +	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED,
> dev_configure
> +	 * cannot be called.
> +	 *
> +	 * re-configure the device after changing queue numbers of stopped
> +	 * ports, so that the updated mapping between tc and queue can be
> +	 * obtained.
> +	 */
> +	for (pid = 0; pid < nb_fwd_ports; pid++) {
> +		if (port_is_started(pid) == 1)
> +			continue;
> +
> +		port = &ports[pid];
> +		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
> +					    &port->dev_conf);
> +		if (ret < 0) {
> +			printf("Failed to re-configure port %d, ret = %d.\n",
> +				pid, ret);
> +			return;
> +		}
> +	}
> 
>  	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>  	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
> --
> 2.7.4

Re: [dpdk-dev] [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test

[Huisong Li]

在 2021/4/27 19:19, Li, Xiaoyun 写道:
>
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Tuesday, April 20, 2021 17:01
>> To: dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
>> linuxarm@openeuler.org; lihuisong@huawei.com
>> Subject: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test
>>
>> After DCB mode is configured, if we decrease the number of RX and TX queues,
>> fwd_config_setup() will be called to setup the DCB forwarding configuration.
>> And forwarding streams are updated based on new queue numbers in
>> fwd_config_setup(), but the mapping between the TC and queues obtained by
>> rte_eth_dev_get_dcb_info() is still old queue numbers (old queue numbers are
>> greater than new queue numbers).
>> In this case, the segment fault happens. So rte_eth_dev_configure() should be
>> called again to update the mapping between the TC and queues before
>> rte_eth_dev_get_dcb_info().
>>
>> Like:
>> set nbcore 4
>> port stop all
>> port config 0 dcb vt off 4 pfc on
>> port start all
>> port stop all
>> port config all rxq 8
>> port config all txq 8
>>
>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
>>   1 file changed, 26 insertions(+)
>>
>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>> 03ee40c..18b197b 100644
>> --- a/app/test-pmd/config.c
>> +++ b/app/test-pmd/config.c
>> @@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
>>   	uint16_t nb_rx_queue, nb_tx_queue;
>>   	uint16_t i, j, k, sm_id = 0;
>>   	uint16_t total_tc_num;
>> +	struct rte_port *port;
>>   	uint8_t tc = 0;
>> +	portid_t pid;
>> +	int ret;
>> +
>> +	/*
>> +	 * The fwd_config_setup() is called when the port is
>> RTE_PORT_STARTED
> When the port is RTE_PORT_STARTED or RTE_PORT_STARTED? Missing an 'or' here.
ok
> Maybe something like the following will be better? (just a reference, you can put it in a better way)
> /*
>    * Re-configure ports to get updated mapping between tc and queue in case the queue number of the port is changed.
>    * Skip for started ports since configuring queue number needs to stop ports first.
>    */

Thank you😁 I'm going to fix it as follows:

     /*
      * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
      * or RTE_PORT_STOPPED.
      *
      * Re-configure ports to get updated mapping between tc and queue when
      * the queue number of the port is changed. Skip for started ports 
since
      * modifying queue number and calling dev_configure need to stop ports
      * first.
      */

>> +	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED,
>> dev_configure
>> +	 * cannot be called.
>> +	 *
>> +	 * re-configure the device after changing queue numbers of stopped
>> +	 * ports, so that the updated mapping between tc and queue can be
>> +	 * obtained.
>> +	 */
>> +	for (pid = 0; pid < nb_fwd_ports; pid++) {
>> +		if (port_is_started(pid) == 1)
>> +			continue;
>> +
>> +		port = &ports[pid];
>> +		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
>> +					    &port->dev_conf);
>> +		if (ret < 0) {
>> +			printf("Failed to re-configure port %d, ret = %d.\n",
>> +				pid, ret);
>> +			return;
>> +		}
>> +	}
>>
>>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>> --
>> 2.7.4
> .

Re: [dpdk-dev] [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 27, 2021 22:11
> To: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: Re: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test
> 
> 
> 在 2021/4/27 19:19, Li, Xiaoyun 写道:
> >
> >> -----Original Message-----
> >> From: Huisong Li <lihuisong@huawei.com>
> >> Sent: Tuesday, April 20, 2021 17:01
> >> To: dev@dpdk.org
> >> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun
> >> <xiaoyun.li@intel.com>; linuxarm@openeuler.org; lihuisong@huawei.com
> >> Subject: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB
> >> test
> >>
> >> After DCB mode is configured, if we decrease the number of RX and TX
> >> queues,
> >> fwd_config_setup() will be called to setup the DCB forwarding configuration.
> >> And forwarding streams are updated based on new queue numbers in
> >> fwd_config_setup(), but the mapping between the TC and queues
> >> obtained by
> >> rte_eth_dev_get_dcb_info() is still old queue numbers (old queue
> >> numbers are greater than new queue numbers).
> >> In this case, the segment fault happens. So rte_eth_dev_configure()
> >> should be called again to update the mapping between the TC and
> >> queues before rte_eth_dev_get_dcb_info().
> >>
> >> Like:
> >> set nbcore 4
> >> port stop all
> >> port config 0 dcb vt off 4 pfc on
> >> port start all
> >> port stop all
> >> port config all rxq 8
> >> port config all txq 8
> >>
> >> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> >> ---
> >>   app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
> >>   1 file changed, 26 insertions(+)
> >>
> >> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> >> 03ee40c..18b197b 100644
> >> --- a/app/test-pmd/config.c
> >> +++ b/app/test-pmd/config.c
> >> @@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
> >>   	uint16_t nb_rx_queue, nb_tx_queue;
> >>   	uint16_t i, j, k, sm_id = 0;
> >>   	uint16_t total_tc_num;
> >> +	struct rte_port *port;
> >>   	uint8_t tc = 0;
> >> +	portid_t pid;
> >> +	int ret;
> >> +
> >> +	/*
> >> +	 * The fwd_config_setup() is called when the port is
> >> RTE_PORT_STARTED
> > When the port is RTE_PORT_STARTED or RTE_PORT_STARTED? Missing an 'or'
> here.
> ok
> > Maybe something like the following will be better? (just a reference,
> > you can put it in a better way)
> > /*
> >    * Re-configure ports to get updated mapping between tc and queue in case
> the queue number of the port is changed.
> >    * Skip for started ports since configuring queue number needs to stop ports
> first.
> >    */
> 
> Thank you😁 I'm going to fix it as follows:
> 
>      /*
>       * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
>       * or RTE_PORT_STOPPED.
>       *
>       * Re-configure ports to get updated mapping between tc and queue when
>       * the queue number of the port is changed. Skip for started ports since
>       * modifying queue number and calling dev_configure need to stop ports
>       * first.
>       */
> 
Overall, looks good to me.
Just one suggestion, what about change "when the queue number" to "in case the queue number" because you actually don't know if the queue number is changed or not.

> >> +	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED,
> >> dev_configure
> >> +	 * cannot be called.
> >> +	 *
> >> +	 * re-configure the device after changing queue numbers of stopped
> >> +	 * ports, so that the updated mapping between tc and queue can be
> >> +	 * obtained.
> >> +	 */
> >> +	for (pid = 0; pid < nb_fwd_ports; pid++) {
> >> +		if (port_is_started(pid) == 1)
> >> +			continue;
> >> +
> >> +		port = &ports[pid];
> >> +		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
> >> +					    &port->dev_conf);
> >> +		if (ret < 0) {
> >> +			printf("Failed to re-configure port %d, ret = %d.\n",
> >> +				pid, ret);
> >> +			return;
> >> +		}
> >> +	}
> >>
> >>   	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
> >>   	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
> >> --
> >> 2.7.4
> > .

Re: [dpdk-dev] [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test

[Huisong Li]

在 2021/4/28 10:02, Li, Xiaoyun 写道:
>
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Tuesday, April 27, 2021 22:11
>> To: Li, Xiaoyun <xiaoyun.li@intel.com>; dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>
>> Subject: Re: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB test
>>
>>
>> 在 2021/4/27 19:19, Li, Xiaoyun 写道:
>>>> -----Original Message-----
>>>> From: Huisong Li <lihuisong@huawei.com>
>>>> Sent: Tuesday, April 20, 2021 17:01
>>>> To: dev@dpdk.org
>>>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun
>>>> <xiaoyun.li@intel.com>; linuxarm@openeuler.org; lihuisong@huawei.com
>>>> Subject: [PATCH V3 3/7] app/testpmd: fix a segment fault when DCB
>>>> test
>>>>
>>>> After DCB mode is configured, if we decrease the number of RX and TX
>>>> queues,
>>>> fwd_config_setup() will be called to setup the DCB forwarding configuration.
>>>> And forwarding streams are updated based on new queue numbers in
>>>> fwd_config_setup(), but the mapping between the TC and queues
>>>> obtained by
>>>> rte_eth_dev_get_dcb_info() is still old queue numbers (old queue
>>>> numbers are greater than new queue numbers).
>>>> In this case, the segment fault happens. So rte_eth_dev_configure()
>>>> should be called again to update the mapping between the TC and
>>>> queues before rte_eth_dev_get_dcb_info().
>>>>
>>>> Like:
>>>> set nbcore 4
>>>> port stop all
>>>> port config 0 dcb vt off 4 pfc on
>>>> port start all
>>>> port stop all
>>>> port config all rxq 8
>>>> port config all txq 8
>>>>
>>>> Fixes: 900550de04a7 ("app/testpmd: add dcb support")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>>>> ---
>>>>    app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
>>>>    1 file changed, 26 insertions(+)
>>>>
>>>> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
>>>> 03ee40c..18b197b 100644
>>>> --- a/app/test-pmd/config.c
>>>> +++ b/app/test-pmd/config.c
>>>> @@ -2996,7 +2996,33 @@ dcb_fwd_config_setup(void)
>>>>    	uint16_t nb_rx_queue, nb_tx_queue;
>>>>    	uint16_t i, j, k, sm_id = 0;
>>>>    	uint16_t total_tc_num;
>>>> +	struct rte_port *port;
>>>>    	uint8_t tc = 0;
>>>> +	portid_t pid;
>>>> +	int ret;
>>>> +
>>>> +	/*
>>>> +	 * The fwd_config_setup() is called when the port is
>>>> RTE_PORT_STARTED
>>> When the port is RTE_PORT_STARTED or RTE_PORT_STARTED? Missing an 'or'
>> here.
>> ok
>>> Maybe something like the following will be better? (just a reference,
>>> you can put it in a better way)
>>> /*
>>>     * Re-configure ports to get updated mapping between tc and queue in case
>> the queue number of the port is changed.
>>>     * Skip for started ports since configuring queue number needs to stop ports
>> first.
>>>     */
>> Thank you😁 I'm going to fix it as follows:
>>
>>       /*
>>        * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
>>        * or RTE_PORT_STOPPED.
>>        *
>>        * Re-configure ports to get updated mapping between tc and queue when
>>        * the queue number of the port is changed. Skip for started ports since
>>        * modifying queue number and calling dev_configure need to stop ports
>>        * first.
>>        */
>>
> Overall, looks good to me.
> Just one suggestion, what about change "when the queue number" to "in case the queue number" because you actually don't know if the queue number is changed or not.
Yes, there is a difference in meaning. I will fix it in next version.
>
>>>> +	 * RTE_PORT_STOPPED. When a port is RTE_PORT_STARTED,
>>>> dev_configure
>>>> +	 * cannot be called.
>>>> +	 *
>>>> +	 * re-configure the device after changing queue numbers of stopped
>>>> +	 * ports, so that the updated mapping between tc and queue can be
>>>> +	 * obtained.
>>>> +	 */
>>>> +	for (pid = 0; pid < nb_fwd_ports; pid++) {
>>>> +		if (port_is_started(pid) == 1)
>>>> +			continue;
>>>> +
>>>> +		port = &ports[pid];
>>>> +		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
>>>> +					    &port->dev_conf);
>>>> +		if (ret < 0) {
>>>> +			printf("Failed to re-configure port %d, ret = %d.\n",
>>>> +				pid, ret);
>>>> +			return;
>>>> +		}
>>>> +	}
>>>>
>>>>    	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
>>>>    	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
>>>> --
>>>> 2.7.4
>>> .

[dpdk-dev] [PATCH V3 4/7] app/testpmd: add check for support of reporting DCB info

[Huisong Li]

Currently, '.get_dcb_info' must be supported for the port doing DCB test,
or all information in 'rte_eth_dcb_info' are zero. It should be prevented
when user run cmd "port config 0 dcb vt off 4 pfc off".

This patch adds the check for support of reporting dcb info.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
V2->V3
- fix the abnormal print information

---
 app/test-pmd/cmdline.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d282c7c..6329730 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3170,6 +3170,7 @@ cmd_config_dcb_parsed(void *parsed_result,
                         __rte_unused void *data)
 {
 	struct cmd_config_dcb *res = parsed_result;
+	struct rte_eth_dcb_info dcb_info;
 	portid_t port_id = res->port_id;
 	struct rte_port *port;
 	uint8_t pfc_en;
@@ -3192,6 +3193,14 @@ cmd_config_dcb_parsed(void *parsed_result,
 		printf("nb_cores shouldn't be less than number of TCs.\n");
 		return;
 	}
+
+	/* Check whether the port supports the report of DCB info. */
+	ret = rte_eth_dev_get_dcb_info(port_id, &dcb_info);
+	if (ret == -ENOTSUP) {
+		printf("The port must support rte_eth_dev_get_dcb_info API, or can't do dcb test.\n");
+		return;
+	}
+
 	if (!strncmp(res->pfc_en, "on", 2))
 		pfc_en = 1;
 	else
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 4/7] app/testpmd: add check for support of reporting DCB info

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 4/7] app/testpmd: add check for support of reporting DCB
> info
> 
> Currently, '.get_dcb_info' must be supported for the port doing DCB test, or all
> information in 'rte_eth_dcb_info' are zero. It should be prevented when user run
> cmd "port config 0 dcb vt off 4 pfc off".
> 
> This patch adds the check for support of reporting dcb info.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
> V2->V3
> - fix the abnormal print information
> 
> ---
>  app/test-pmd/cmdline.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 2.7.4

Acked-by: Xiaoyun Li <xiaoyun.li@intel.com>

[dpdk-dev] [PATCH V3 5/7] app/testpmd: move position of verifying DCB test

[Huisong Li]

Currently, the check for doing DCB test is assigned to
start_packet_forwarding(), which will be called when
run "start" cmd. But fwd_config_setup() is used in many
scenarios, such as, "port config all rxq".

This patch moves the check from start_packet_forwarding()
to fwd_config_setup().

Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c  | 23 +++++++++++++++++++++--
 app/test-pmd/testpmd.c | 19 -------------------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 18b197b..66974f8 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3152,6 +3152,10 @@ icmp_echo_config_setup(void)
 void
 fwd_config_setup(void)
 {
+	struct rte_port *port;
+	portid_t pt_id;
+	unsigned int i;
+
 	cur_fwd_config.fwd_eng = cur_fwd_eng;
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "icmpecho") == 0) {
 		icmp_echo_config_setup();
@@ -3159,9 +3163,24 @@ fwd_config_setup(void)
 	}
 
 	if ((nb_rxq > 1) && (nb_txq > 1)){
-		if (dcb_config)
+		if (dcb_config) {
+			for (i = 0; i < nb_fwd_ports; i++) {
+				pt_id = fwd_ports_ids[i];
+				port = &ports[pt_id];
+				if (!port->dcb_flag) {
+					printf("In DCB mode, all forwarding ports must "
+						"be configured in this mode.\n");
+					return;
+				}
+			}
+			if (nb_fwd_lcores == 1) {
+				printf("In DCB mode,the nb forwarding cores "
+					"should be larger than 1.\n");
+				return;
+			}
+
 			dcb_fwd_config_setup();
-		else
+		} else
 			rss_fwd_config_setup();
 	}
 	else
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index a076b1d..abcbdaa 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2138,9 +2138,7 @@ start_packet_forwarding(int with_tx_first)
 {
 	port_fwd_begin_t port_fwd_begin;
 	port_fwd_end_t  port_fwd_end;
-	struct rte_port *port;
 	unsigned int i;
-	portid_t   pt_id;
 
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "rxonly") == 0 && !nb_rxq)
 		rte_exit(EXIT_FAILURE, "rxq are 0, cannot use rxonly fwd mode\n");
@@ -2163,23 +2161,6 @@ start_packet_forwarding(int with_tx_first)
 		printf("Packet forwarding already started\n");
 		return;
 	}
-
-	if (dcb_config) {
-		for (i = 0; i < nb_fwd_ports; i++) {
-			pt_id = fwd_ports_ids[i];
-			port = &ports[pt_id];
-			if (!port->dcb_flag) {
-				printf("In DCB mode, all forwarding ports must "
-                                       "be configured in this mode.\n");
-				return;
-			}
-		}
-		if (nb_fwd_lcores == 1) {
-			printf("In DCB mode,the nb forwarding cores "
-                               "should be larger than 1.\n");
-			return;
-		}
-	}
 	test_done = 0;
 
 	fwd_config_setup();
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 5/7] app/testpmd: move position of verifying DCB test

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 5/7] app/testpmd: move position of verifying DCB test
> 
> Currently, the check for doing DCB test is assigned to start_packet_forwarding(),
> which will be called when run "start" cmd. But fwd_config_setup() is used in
> many scenarios, such as, "port config all rxq".
> 
> This patch moves the check from start_packet_forwarding() to
> fwd_config_setup().
> 
> Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/config.c  | 23 +++++++++++++++++++++--  app/test-
> pmd/testpmd.c | 19 -------------------
>  2 files changed, 21 insertions(+), 21 deletions(-)

Acked-by: Xiaoyun Li <xiaoyun.li@intel.com>

[dpdk-dev] [PATCH V3 6/7] app/testpmd: add forwarding config in start port

[Huisong Li]

Most operations in testpmd that need to update the forwarding streams
in testpmd call fwd_config_setup(). In some scenarios, eg, dev_configure
is called again, the forwarding streams may not be updated. As a result,
the actual forwarding streams cannot be queried by "show config fwd" cmd.

The procedure is as follows:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
show config fwd

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index abcbdaa..f8052b6 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2678,6 +2678,12 @@ start_port(portid_t pid)
 			}
 		}
 	}
+	/*
+	 * In some scenarios, eg, dev_configure is called again, the forwarding
+	 * streams may not be updated. As a result, the actual forwarding
+	 * streams cannot be queried by "show config fwd" command.
+	 */
+	fwd_config_setup();
 
 	printf("Done\n");
 	return 0;
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 6/7] app/testpmd: add forwarding config in start port

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 6/7] app/testpmd: add forwarding config in start port
> 
> Most operations in testpmd that need to update the forwarding streams in
> testpmd call fwd_config_setup(). In some scenarios, eg, dev_configure is called
> again, the forwarding streams may not be updated. As a result, the actual
> forwarding streams cannot be queried by "show config fwd" cmd.

I don't agree on this.
Fwd config should be only changed after the user change something like nb-cores, queue number, eth-peer in non-dcb mode. These are already done in those commands.

You should do fwd_config_setup at the end of cmd_config_dcb_parsed(), I agree on this.
But doing it in start port seems to do redundant times of fwd_setup. It's not really needed.

> 
> The procedure is as follows:
> set nbcore 4
> port stop all
> port config 0 dcb vt off 4 pfc on
> port start all
> show config fwd
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
>  app/test-pmd/testpmd.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> abcbdaa..f8052b6 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2678,6 +2678,12 @@ start_port(portid_t pid)
>  			}
>  		}
>  	}
> +	/*
> +	 * In some scenarios, eg, dev_configure is called again, the forwarding
> +	 * streams may not be updated. As a result, the actual forwarding
> +	 * streams cannot be queried by "show config fwd" command.
> +	 */
> +	fwd_config_setup();
> 
>  	printf("Done\n");
>  	return 0;
> --
> 2.7.4

Re: [dpdk-dev] [PATCH V3 6/7] app/testpmd: add forwarding config in start port

[Huisong Li]

在 2021/4/27 19:43, Li, Xiaoyun 写道:
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Tuesday, April 20, 2021 17:01
>> To: dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
>> linuxarm@openeuler.org; lihuisong@huawei.com
>> Subject: [PATCH V3 6/7] app/testpmd: add forwarding config in start port
>>
>> Most operations in testpmd that need to update the forwarding streams in
>> testpmd call fwd_config_setup(). In some scenarios, eg, dev_configure is called
>> again, the forwarding streams may not be updated. As a result, the actual
>> forwarding streams cannot be queried by "show config fwd" cmd.
> I don't agree on this.
> Fwd config should be only changed after the user change something like nb-cores, queue number, eth-peer in non-dcb mode. These are already done in those commands.
>
> You should do fwd_config_setup at the end of cmd_config_dcb_parsed(), I agree on this.
> But doing it in start port seems to do redundant times of fwd_setup. It's not really needed.
After moving the check of dcb test to fwd_config_setup() in this patch 
set, doing fwd_config_setup at the end of cmd_config_dcb_parsed() does 
make more sense.
In this way, similar commands can maintain the same design.  And I 
tested it, and it was OK. I will fix it in next version, thanks.
>> The procedure is as follows:
>> set nbcore 4
>> port stop all
>> port config 0 dcb vt off 4 pfc on
>> port start all
>> show config fwd
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>>   app/test-pmd/testpmd.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>> abcbdaa..f8052b6 100644
>> --- a/app/test-pmd/testpmd.c
>> +++ b/app/test-pmd/testpmd.c
>> @@ -2678,6 +2678,12 @@ start_port(portid_t pid)
>>   			}
>>   		}
>>   	}
>> +	/*
>> +	 * In some scenarios, eg, dev_configure is called again, the forwarding
>> +	 * streams may not be updated. As a result, the actual forwarding
>> +	 * streams cannot be queried by "show config fwd" command.
>> +	 */
>> +	fwd_config_setup();
>>
>>   	printf("Done\n");
>>   	return 0;
>> --
>> 2.7.4
> .

[dpdk-dev] [PATCH V3 7/7] app/testpmd: remove redundant fwd streams initialization

[Huisong Li]

The fwd_config_setup() is called after init_fwd_streams().
The fwd_config_setup() will reinitialize forwarding streams.
This patch removes init_fwd_streams() from init_config().

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index f8052b6..79b5d97 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1576,10 +1576,6 @@ init_config(void)
 		fwd_lcores[lc_id]->gso_ctx.flag = 0;
 	}
 
-	/* Configuration of packet forwarding streams. */
-	if (init_fwd_streams() < 0)
-		rte_exit(EXIT_FAILURE, "FAIL from init_fwd_streams()\n");
-
 	fwd_config_setup();
 
 	/* create a gro context for each lcore */
-- 
2.7.4

Re: [dpdk-dev] [PATCH V3 7/7] app/testpmd: remove redundant fwd streams initialization

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Tuesday, April 20, 2021 17:01
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>;
> linuxarm@openeuler.org; lihuisong@huawei.com
> Subject: [PATCH V3 7/7] app/testpmd: remove redundant fwd streams
> initialization
> 
> The fwd_config_setup() is called after init_fwd_streams().
> The fwd_config_setup() will reinitialize forwarding streams.
> This patch removes init_fwd_streams() from init_config().
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> ---
Agree. Seems redundant. Every fwd setup will call init_fwd_streams() again.

Acked-by: Xiaoyun Li <xiaoyun.li@intel.com>

[dpdk-dev] [PATCH V4 0/7] modifications about DCB forwarding configuration

[Huisong Li]

This patchset modifies some codes about DCB forwarding configuration.
It mainly includes:
- fix forward lcores number when DCB test
- remove dcb_test
- fix a segment fault when dcb test
- add check for support of reporting DCB info
- move position of verifying DCB test
- add forwarding configuration when config DCB
- remove redundant fwd streams initialization

---
V3->V4:
 - fix some commit log and code comments
 - add forwarding configuration when configure DCB instead of start port

V2->V3
 - fix abnormal print information

V1->V2
 - remove patch "app/testpmd: use of Rx/Tx in testpmd"
 - fix patch title
 - remove dcb_test
 - add some new adjustments

---

Huisong Li (7):
  app/testpmd: fix forward lcores number when DCB test
  app/testpmd: fix DCB forwarding configuration
  app/testpmd: fix a segment fault when DCB test
  app/testpmd: add check for support of reporting DCB info
  app/testpmd: move position of verifying DCB test
  app/testpmd: add forwarding configuration when config DCB
  app/testpmd: remove redundant fwd streams initialization

 app/test-pmd/cmdline.c | 13 ++++++++--
 app/test-pmd/config.c  | 68 ++++++++++++++++++++++++++++++++++++++++++--
 app/test-pmd/testpmd.c | 39 +++--------------------------
 app/test-pmd/testpmd.h |  1 -
 4 files changed, 80 insertions(+), 41 deletions(-)

-- 
2.7.4

[dpdk-dev] [PATCH V4 1/7] app/testpmd: fix forward lcores number when DCB test

[Huisong Li]

For the DCB forwarding test, each core is assigned to each traffic class.
Number of forwarding cores for DCB test must be equal or less than number
of total TC. Otherwise, the following problems may occur:
1/ Redundant polling threads will be created when forwarding cores number
   is greater than total TC number.
2/ Two cores would try to use a same queue on a port when Rx/Tx queue
   number is greater than the used TC number, which is not allowed.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index a4445a7..39c0b80 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3008,6 +3008,21 @@ rss_fwd_config_setup(void)
 	}
 }
 
+static uint16_t
+get_fwd_port_total_tc_num(void)
+{
+	struct rte_eth_dcb_info dcb_info;
+	uint16_t total_tc_num = 0;
+	unsigned int i;
+
+	for (i = 0; i < nb_fwd_ports; i++) {
+		(void)rte_eth_dev_get_dcb_info(fwd_ports_ids[i], &dcb_info);
+		total_tc_num += dcb_info.nb_tcs;
+	}
+
+	return total_tc_num;
+}
+
 /**
  * For the DCB forwarding test, each core is assigned on each traffic class.
  *
@@ -3027,12 +3042,16 @@ dcb_fwd_config_setup(void)
 	lcoreid_t  lc_id;
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
+	uint16_t total_tc_num;
 	uint8_t tc = 0;
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
 	cur_fwd_config.nb_fwd_streams =
 		(streamid_t) (nb_rxq * cur_fwd_config.nb_fwd_ports);
+	total_tc_num = get_fwd_port_total_tc_num();
+	if (cur_fwd_config.nb_fwd_lcores > total_tc_num)
+		cur_fwd_config.nb_fwd_lcores = total_tc_num;
 
 	/* reinitialize forwarding streams */
 	init_fwd_streams();
-- 
2.7.4

[dpdk-dev] [PATCH V4 2/7] app/testpmd: fix DCB forwarding configuration

[Huisong Li]

After DCB mode is configured, the operations of port stop and port start
change the value of the global variable "dcb_test", As a result, the
forwarding configuration from DCB to RSS mode, namely,
“dcb_fwd_config_setup()” to "rss_fwd_config_setup()".

Currently, the 'dcb_flag' field in struct 'rte_port' indicates whether
the port is configured with DCB. And it is sufficient to have 'dcb_config'
as a global variable to control the DCB test status. So this patch deletes
the "dcb_test".

In addition, setting 'dcb_config' at the end of init_port_dcb_config() in
case that ports fail to enter DCB mode.

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 18 ++++--------------
 app/test-pmd/testpmd.h |  1 -
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index d4be23f..a076b1d 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -246,9 +246,6 @@ uint16_t mb_mempool_cache = DEF_MBUF_CACHE; /**< Size of mbuf mempool cache. */
 /* current configuration is in DCB or not,0 means it is not in DCB mode */
 uint8_t dcb_config = 0;
 
-/* Whether the dcb is in testing status */
-uint8_t dcb_test = 0;
-
 /*
  * Configurable number of RX/TX queues.
  */
@@ -2167,8 +2164,7 @@ start_packet_forwarding(int with_tx_first)
 		return;
 	}
 
-
-	if(dcb_test) {
+	if (dcb_config) {
 		for (i = 0; i < nb_fwd_ports; i++) {
 			pt_id = fwd_ports_ids[i];
 			port = &ports[pt_id];
@@ -2476,8 +2472,6 @@ start_port(portid_t pid)
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return 0;
 
-	if(dcb_config)
-		dcb_test = 1;
 	RTE_ETH_FOREACH_DEV(pi) {
 		if (pid != pi && pid != (portid_t)RTE_PORT_ALL)
 			continue;
@@ -2717,11 +2711,6 @@ stop_port(portid_t pid)
 	portid_t peer_pl[RTE_MAX_ETHPORTS];
 	int peer_pi;
 
-	if (dcb_test) {
-		dcb_test = 0;
-		dcb_config = 0;
-	}
-
 	if (port_id_is_invalid(pid, ENABLED_WARN))
 		return;
 
@@ -3625,8 +3614,6 @@ init_port_dcb_config(portid_t pid,
 	rte_port = &ports[pid];
 
 	memset(&port_conf, 0, sizeof(struct rte_eth_conf));
-	/* Enter DCB configuration status */
-	dcb_config = 1;
 
 	port_conf.rxmode = rte_port->dev_conf.rxmode;
 	port_conf.txmode = rte_port->dev_conf.txmode;
@@ -3694,6 +3681,9 @@ init_port_dcb_config(portid_t pid,
 
 	rte_port->dcb_flag = 1;
 
+	/* Enter DCB configuration status */
+	dcb_config = 1;
+
 	return 0;
 }
 
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 6ca872d..283b5e3 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -425,7 +425,6 @@ extern uint64_t noisy_lkup_num_reads;
 extern uint64_t noisy_lkup_num_reads_writes;
 
 extern uint8_t dcb_config;
-extern uint8_t dcb_test;
 
 extern uint32_t mbuf_data_size_n;
 extern uint16_t mbuf_data_size[MAX_SEGS_BUFFER_SPLIT];
-- 
2.7.4

[dpdk-dev] [PATCH V4 3/7] app/testpmd: fix a segment fault when DCB test

[Huisong Li]

After DCB mode is configured, if we decrease the number of RX and TX
queues, fwd_config_setup() will be called to setup the DCB forwarding
configuration. And forwarding streams are updated based on new queue
numbers in fwd_config_setup(), but the mapping between the TC and
queues obtained by rte_eth_dev_get_dcb_info() is still old queue
numbers (old queue numbers are greater than new queue numbers).
In this case, the segment fault happens. So rte_eth_dev_configure()
should be called again to update the mapping between the TC and
queues before rte_eth_dev_get_dcb_info().

Like:
set nbcore 4
port stop all
port config 0 dcb vt off 4 pfc on
port start all
port stop all
port config all rxq 8
port config all txq 8

Fixes: 900550de04a7 ("app/testpmd: add dcb support")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 39c0b80..bbf039d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3043,7 +3043,33 @@ dcb_fwd_config_setup(void)
 	uint16_t nb_rx_queue, nb_tx_queue;
 	uint16_t i, j, k, sm_id = 0;
 	uint16_t total_tc_num;
+	struct rte_port *port;
 	uint8_t tc = 0;
+	portid_t pid;
+	int ret;
+
+	/*
+	 * The fwd_config_setup() is called when the port is RTE_PORT_STARTED
+	 * or RTE_PORT_STOPPED.
+	 *
+	 * Re-configure ports to get updated mapping between tc and queue in
+	 * case the queue number of the port is changed. Skip for started ports
+	 * since modifying queue number and calling dev_configure need to stop
+	 * ports first.
+	 */
+	for (pid = 0; pid < nb_fwd_ports; pid++) {
+		if (port_is_started(pid) == 1)
+			continue;
+
+		port = &ports[pid];
+		ret = rte_eth_dev_configure(pid, nb_rxq, nb_txq,
+					    &port->dev_conf);
+		if (ret < 0) {
+			printf("Failed to re-configure port %d, ret = %d.\n",
+				pid, ret);
+			return;
+		}
+	}
 
 	cur_fwd_config.nb_fwd_lcores = (lcoreid_t) nb_fwd_lcores;
 	cur_fwd_config.nb_fwd_ports = nb_fwd_ports;
-- 
2.7.4

[dpdk-dev] [PATCH V4 4/7] app/testpmd: add check for support of reporting DCB info

[Huisong Li]

Currently, '.get_dcb_info' must be supported for the port doing DCB test,
or all information in 'rte_eth_dcb_info' are zero. It should be prevented
when user run cmd "port config 0 dcb vt off 4 pfc off".

This patch adds the check for support of reporting dcb info.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/cmdline.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5fdcc1c..14750b3 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3270,6 +3270,7 @@ cmd_config_dcb_parsed(void *parsed_result,
                         __rte_unused void *data)
 {
 	struct cmd_config_dcb *res = parsed_result;
+	struct rte_eth_dcb_info dcb_info;
 	portid_t port_id = res->port_id;
 	struct rte_port *port;
 	uint8_t pfc_en;
@@ -3292,6 +3293,14 @@ cmd_config_dcb_parsed(void *parsed_result,
 		printf("nb_cores shouldn't be less than number of TCs.\n");
 		return;
 	}
+
+	/* Check whether the port supports the report of DCB info. */
+	ret = rte_eth_dev_get_dcb_info(port_id, &dcb_info);
+	if (ret == -ENOTSUP) {
+		printf("The port must support rte_eth_dev_get_dcb_info API, or can't do dcb test.\n");
+		return;
+	}
+
 	if (!strncmp(res->pfc_en, "on", 2))
 		pfc_en = 1;
 	else
-- 
2.7.4

[dpdk-dev] [PATCH V4 5/7] app/testpmd: move position of verifying DCB test

[Huisong Li]

Currently, the check for doing DCB test is assigned to
start_packet_forwarding(), which will be called when
run "start" cmd. But fwd_config_setup() is used in many
scenarios, such as, "port config all rxq".

This patch moves the check from start_packet_forwarding()
to fwd_config_setup().

Fixes: 7741e4cf16c0 ("app/testpmd: VMDq and DCB updates")

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/config.c  | 23 +++++++++++++++++++++--
 app/test-pmd/testpmd.c | 19 -------------------
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index bbf039d..fc057e5 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3199,6 +3199,10 @@ icmp_echo_config_setup(void)
 void
 fwd_config_setup(void)
 {
+	struct rte_port *port;
+	portid_t pt_id;
+	unsigned int i;
+
 	cur_fwd_config.fwd_eng = cur_fwd_eng;
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "icmpecho") == 0) {
 		icmp_echo_config_setup();
@@ -3206,9 +3210,24 @@ fwd_config_setup(void)
 	}
 
 	if ((nb_rxq > 1) && (nb_txq > 1)){
-		if (dcb_config)
+		if (dcb_config) {
+			for (i = 0; i < nb_fwd_ports; i++) {
+				pt_id = fwd_ports_ids[i];
+				port = &ports[pt_id];
+				if (!port->dcb_flag) {
+					printf("In DCB mode, all forwarding ports must "
+						"be configured in this mode.\n");
+					return;
+				}
+			}
+			if (nb_fwd_lcores == 1) {
+				printf("In DCB mode,the nb forwarding cores "
+					"should be larger than 1.\n");
+				return;
+			}
+
 			dcb_fwd_config_setup();
-		else
+		} else
 			rss_fwd_config_setup();
 	}
 	else
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index a076b1d..abcbdaa 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2138,9 +2138,7 @@ start_packet_forwarding(int with_tx_first)
 {
 	port_fwd_begin_t port_fwd_begin;
 	port_fwd_end_t  port_fwd_end;
-	struct rte_port *port;
 	unsigned int i;
-	portid_t   pt_id;
 
 	if (strcmp(cur_fwd_eng->fwd_mode_name, "rxonly") == 0 && !nb_rxq)
 		rte_exit(EXIT_FAILURE, "rxq are 0, cannot use rxonly fwd mode\n");
@@ -2163,23 +2161,6 @@ start_packet_forwarding(int with_tx_first)
 		printf("Packet forwarding already started\n");
 		return;
 	}
-
-	if (dcb_config) {
-		for (i = 0; i < nb_fwd_ports; i++) {
-			pt_id = fwd_ports_ids[i];
-			port = &ports[pt_id];
-			if (!port->dcb_flag) {
-				printf("In DCB mode, all forwarding ports must "
-                                       "be configured in this mode.\n");
-				return;
-			}
-		}
-		if (nb_fwd_lcores == 1) {
-			printf("In DCB mode,the nb forwarding cores "
-                               "should be larger than 1.\n");
-			return;
-		}
-	}
 	test_done = 0;
 
 	fwd_config_setup();
-- 
2.7.4

[dpdk-dev] [PATCH V4 6/7] app/testpmd: add forwarding configuration when config DCB

[Huisong Li]

This patch adds fwd_config_setup() at the end of cmd_config_dcb_parsed()
to update "cur_fwd_config", so that the actual forwarding streams can be
queried by the "show config fwd" cmd.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/cmdline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 14750b3..2e7604d 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -3315,13 +3315,13 @@ cmd_config_dcb_parsed(void *parsed_result,
 		ret = init_port_dcb_config(port_id, DCB_ENABLED,
 				(enum rte_eth_nb_tcs)res->num_tcs,
 				pfc_en);
-
-
 	if (ret != 0) {
 		printf("Cannot initialize network ports.\n");
 		return;
 	}
 
+	fwd_config_setup();
+
 	cmd_reconfig_device_queue(port_id, 1, 1);
 }
 
-- 
2.7.4

[dpdk-dev] [PATCH V4 7/7] app/testpmd: remove redundant fwd streams initialization

[Huisong Li]

The fwd_config_setup() is called after init_fwd_streams().
The fwd_config_setup() will reinitialize forwarding streams.
This patch removes init_fwd_streams() from init_config().

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Signed-off-by: Lijun Ou <oulijun@huawei.com>
---
 app/test-pmd/testpmd.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index abcbdaa..8ed1b97 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1576,10 +1576,6 @@ init_config(void)
 		fwd_lcores[lc_id]->gso_ctx.flag = 0;
 	}
 
-	/* Configuration of packet forwarding streams. */
-	if (init_fwd_streams() < 0)
-		rte_exit(EXIT_FAILURE, "FAIL from init_fwd_streams()\n");
-
 	fwd_config_setup();
 
 	/* create a gro context for each lcore */
-- 
2.7.4

Re: [dpdk-dev] [PATCH V4 0/7] modifications about DCB forwarding configuration

[Li, Xiaoyun]

> -----Original Message-----
> From: Huisong Li <lihuisong@huawei.com>
> Sent: Wednesday, April 28, 2021 14:41
> To: dev@dpdk.org
> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>
> Subject: [PATCH V4 0/7] modifications about DCB forwarding configuration
> 
> This patchset modifies some codes about DCB forwarding configuration.
> It mainly includes:
> - fix forward lcores number when DCB test
> - remove dcb_test
> - fix a segment fault when dcb test
> - add check for support of reporting DCB info
> - move position of verifying DCB test
> - add forwarding configuration when config DCB
> - remove redundant fwd streams initialization
> 
> ---
> V3->V4:
>  - fix some commit log and code comments
>  - add forwarding configuration when configure DCB instead of start port
> 
> V2->V3
>  - fix abnormal print information
> 
> V1->V2
>  - remove patch "app/testpmd: use of Rx/Tx in testpmd"
>  - fix patch title
>  - remove dcb_test
>  - add some new adjustments
> 
> ---
> 
> Huisong Li (7):
>   app/testpmd: fix forward lcores number when DCB test
>   app/testpmd: fix DCB forwarding configuration
>   app/testpmd: fix a segment fault when DCB test
>   app/testpmd: add check for support of reporting DCB info
>   app/testpmd: move position of verifying DCB test
>   app/testpmd: add forwarding configuration when config DCB
>   app/testpmd: remove redundant fwd streams initialization
> 
>  app/test-pmd/cmdline.c | 13 ++++++++--
>  app/test-pmd/config.c  | 68
> ++++++++++++++++++++++++++++++++++++++++++--
>  app/test-pmd/testpmd.c | 39 +++--------------------------  app/test-
> pmd/testpmd.h |  1 -
>  4 files changed, 80 insertions(+), 41 deletions(-)
> 
> --
> 2.7.4

Acked-by: Xiaoyun Li <xiaoyun.li@intel.com>

Re: [dpdk-dev] [PATCH V4 0/7] modifications about DCB forwarding configuration

[Ferruh Yigit]

On 4/28/2021 8:01 AM, Li, Xiaoyun wrote:
>> -----Original Message-----
>> From: Huisong Li <lihuisong@huawei.com>
>> Sent: Wednesday, April 28, 2021 14:41
>> To: dev@dpdk.org
>> Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>
>> Subject: [PATCH V4 0/7] modifications about DCB forwarding configuration
>>
>> This patchset modifies some codes about DCB forwarding configuration.
>> It mainly includes:
>> - fix forward lcores number when DCB test
>> - remove dcb_test
>> - fix a segment fault when dcb test
>> - add check for support of reporting DCB info
>> - move position of verifying DCB test
>> - add forwarding configuration when config DCB
>> - remove redundant fwd streams initialization
>>
>> ---
>> V3->V4:
>>  - fix some commit log and code comments
>>  - add forwarding configuration when configure DCB instead of start port
>>
>> V2->V3
>>  - fix abnormal print information
>>
>> V1->V2
>>  - remove patch "app/testpmd: use of Rx/Tx in testpmd"
>>  - fix patch title
>>  - remove dcb_test
>>  - add some new adjustments
>>
>> ---
>>
>> Huisong Li (7):
>>   app/testpmd: fix forward lcores number when DCB test
>>   app/testpmd: fix DCB forwarding configuration
>>   app/testpmd: fix a segment fault when DCB test
>>   app/testpmd: add check for support of reporting DCB info
>>   app/testpmd: move position of verifying DCB test
>>   app/testpmd: add forwarding configuration when config DCB
>>   app/testpmd: remove redundant fwd streams initialization
>>
>>  app/test-pmd/cmdline.c | 13 ++++++++--
>>  app/test-pmd/config.c  | 68
>> ++++++++++++++++++++++++++++++++++++++++++--
>>  app/test-pmd/testpmd.c | 39 +++--------------------------  app/test-
>> pmd/testpmd.h |  1 -
>>  4 files changed, 80 insertions(+), 41 deletions(-)
>>
>> --
>> 2.7.4
> 
> Acked-by: Xiaoyun Li <xiaoyun.li@intel.com>
> 

Series applied to dpdk-next-net/main, thanks.