From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 9360DA0547;
	Sat, 10 Apr 2021 02:56:36 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 1F258141117;
	Sat, 10 Apr 2021 02:56:36 +0200 (CEST)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by mails.dpdk.org (Postfix) with ESMTP id 644A640688
 for <dev@dpdk.org>; Sat, 10 Apr 2021 02:56:34 +0200 (CEST)
IronPort-SDR: uUOahRbW1sHUYZb2pJJGpYFNfFIFwjquKD9OFZl2qfDBTcyfgrSUrtaH8OhSRRyCinr5kbFyUD
 s9Z5G0z89dXA==
X-IronPort-AV: E=McAfee;i="6000,8403,9949"; a="190673414"
X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="190673414"
Received: from orsmga008.jf.intel.com ([10.7.209.65])
 by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Apr 2021 17:56:33 -0700
IronPort-SDR: xTxi73iBOk9JGUQAlS6EetCzRxszxMbyXxKsua8OoxTAYyh0vg4d8R1urqOPIPpC5VPNtRgc9q
 cZWo64YlociA==
X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="422956241"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.215.191])
 ([10.213.215.191])
 by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 09 Apr 2021 17:56:32 -0700
To: "Li, Xiaoyun" <xiaoyun.li@intel.com>, oulijun <oulijun@huawei.com>,
 "linuxarm@openeuler.org" <linuxarm@openeuler.org>, dev <dev@dpdk.org>
References: <1614939741-63927-1-git-send-email-oulijun@huawei.com>
 <1614939741-63927-2-git-send-email-oulijun@huawei.com>
 <DM4PR11MB5534A8C78C7ADE41F41ECB4C99649@DM4PR11MB5534.namprd11.prod.outlook.com>
 <2a0bee90-2c74-5f07-aaf0-cba8b94944e8@huawei.com>
 <DM4PR11MB5534CE6F3E8961A77083E7BE99639@DM4PR11MB5534.namprd11.prod.outlook.com>
 <918ea8b0-8d5d-ea2b-efce-7995d787b873@huawei.com>
 <DM4PR11MB55345A99567EA390CA26170499629@DM4PR11MB5534.namprd11.prod.outlook.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
X-User: ferruhy
Message-ID: <8caa6ece-eec1-726f-da53-c99ea85aa1be@intel.com>
Date: Sat, 10 Apr 2021 01:56:28 +0100
MIME-Version: 1.0
In-Reply-To: <DM4PR11MB55345A99567EA390CA26170499629@DM4PR11MB5534.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] [Linuxarm] Re: [PATCH 1/3] app/testpmd: fix
 forwarding configuration when DCB test
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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
>>>