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 95D22A0A02;
	Fri, 21 May 2021 08:53:32 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 2302240143;
	Fri, 21 May 2021 08:53:32 +0200 (CEST)
Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32])
 by mails.dpdk.org (Postfix) with ESMTP id C5BB140041
 for <dev@dpdk.org>; Fri, 21 May 2021 08:53:29 +0200 (CEST)
Received: from dggems704-chm.china.huawei.com (unknown [172.30.72.60])
 by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4Fmch80xXkzmVYN;
 Fri, 21 May 2021 14:51:04 +0800 (CST)
Received: from dggpeml500024.china.huawei.com (7.185.36.10) by
 dggems704-chm.china.huawei.com (10.3.19.181) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2176.2; Fri, 21 May 2021 14:53:21 +0800
Received: from [127.0.0.1] (10.40.190.165) by dggpeml500024.china.huawei.com
 (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 21 May
 2021 14:53:21 +0800
To: Ruifeng Wang <Ruifeng.Wang@arm.com>, "thomas@monjalon.net"
 <thomas@monjalon.net>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "jerinj@marvell.com" <jerinj@marvell.com>, 
 "viktorin@rehivetech.com" <viktorin@rehivetech.com>,
 "bruce.richardson@intel.com" <bruce.richardson@intel.com>, "Honnappa
 Nagarahalli" <Honnappa.Nagarahalli@arm.com>, "jerinjacobk@gmail.com"
 <jerinjacobk@gmail.com>, "juraj.linkes@pantheon.tech"
 <juraj.linkes@pantheon.tech>, nd <nd@arm.com>
References: <1620808126-18876-1-git-send-email-fengchengwen@huawei.com>
 <1621430731-27753-1-git-send-email-fengchengwen@huawei.com>
 <1621430731-27753-3-git-send-email-fengchengwen@huawei.com>
 <AM5PR0802MB246596E6CD98D44245F89E559E2A9@AM5PR0802MB2465.eurprd08.prod.outlook.com>
 <54ced40e-f0dd-faf9-2a5c-2a3949812627@huawei.com>
 <AM5PR0802MB2465F097AE761DA2C005EDC29E299@AM5PR0802MB2465.eurprd08.prod.outlook.com>
From: fengchengwen <fengchengwen@huawei.com>
Message-ID: <ad6ae02b-1bc7-bcb5-b4ac-bdf41d6dd7dc@huawei.com>
Date: Fri, 21 May 2021 14:53:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <AM5PR0802MB2465F097AE761DA2C005EDC29E299@AM5PR0802MB2465.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.40.190.165]
X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To
 dggpeml500024.china.huawei.com (7.185.36.10)
X-CFilter-Loop: Reflected
Subject: Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile
 method
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 2021/5/21 13:21, Ruifeng Wang wrote:
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Thursday, May 20, 2021 6:55 PM
>> To: Ruifeng Wang <Ruifeng.Wang@arm.com>; thomas@monjalon.net;
>> ferruh.yigit@intel.com
>> Cc: dev@dpdk.org; jerinj@marvell.com; viktorin@rehivetech.com;
>> bruce.richardson@intel.com; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>>
>>
>> On 2021/5/20 16:24, Ruifeng Wang wrote:
>>>> -----Original Message-----
>>>> From: Chengwen Feng <fengchengwen@huawei.com>
>>>> Sent: Wednesday, May 19, 2021 9:26 PM
>>>> To: thomas@monjalon.net; ferruh.yigit@intel.com
>>>> Cc: dev@dpdk.org; jerinj@marvell.com; Ruifeng Wang
>>>> <Ruifeng.Wang@arm.com>; viktorin@rehivetech.com;
>>>> bruce.richardson@intel.com; Honnappa Nagarahalli
>>>> <Honnappa.Nagarahalli@arm.com>; jerinjacobk@gmail.com;
>>>> juraj.linkes@pantheon.tech; nd <nd@arm.com>
>>>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>>>
>>>> Currently, the SVE code is compiled only when -march supports SVE
>>>> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
>> approach.
>>>>
>>>> The solution:
>>>> a. If the minimum instruction set support SVE then compiles it.
>>>> b. Else if the compiler support SVE then compiles it.
>>>> c. Otherwise don't compile it.
>>>>
>>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>>
>>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>> ---
>>>>  drivers/net/hns3/hns3_rxtx.c |  2 +-  drivers/net/hns3/meson.build |
>>>> 21 ++++++++++++++++++++-
>>>>  2 files changed, 21 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/hns3/hns3_rxtx.c
>>>> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
>>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>>>  static bool
>>>>  hns3_get_sve_support(void)
>>>>  {
>>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>>> +#if defined(CC_SVE_SUPPORT)
>>>>  	if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>>>  		return false;
>>>>  	if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>>> diff --git a/drivers/net/hns3/meson.build
>>>> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
>>>> --- a/drivers/net/hns3/meson.build
>>>> +++ b/drivers/net/hns3/meson.build
>>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>>
>>>>  if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>>>      sources += files('hns3_rxtx_vec.c')
>>>> -    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>> +
>>>> +    # compile SVE when:
>>>> +    # a. support SVE in minimum instruction set baseline
>>>> +    # b. it's not minimum instruction set, but compiler support
>>>> +    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>>> + and
>>>> cc.check_header('arm_sve.h')
>>>> +        cflags += ['-DCC_SVE_SUPPORT']
>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>>>
>>
>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args which
>> support SVE, it can't deals with the situation: the default machine_args don't
>> support SVE but compiler support SVE.
>> So the CC_SVE_SUPPORT marco is necessary.
> Agree that macro for SVE is also needed here. And we can also use '-DCC_SVE_ACLE_SUPPORT' here right?
> I think there is no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT when they are used in source code.
> IMO the same macro name can be used, and it removes redundancy and confusion. 
> 

You are right, no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT
But the hns3 sve already support 20.11, and CC_SVE_ACLE_SUPPORT was newly defined,
there maybe some problems when backporting.

Or we could redefine CC_SVE_ACLE_SUPPORT under default machine_args:
    if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and cc.check_header('arm_sve.h')
        cflags += ['-DCC_SVE_ACLE_SUPPORT']
        sources += files('hns3_rxtx_vec_sve.c')
    elif cc.has_argument('-march=armv8.2-a+sve') and cc.check_header('arm_sve.h')
        sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
        foreach flag: cflags
            # filterout -march -mcpu -mtune
            if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or flag.startswith('-mtune='))
                sve_cflags += flag
            endif
        endforeach
but this way may introduce coupling, I think.

>>
>>> [1]
>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send
>>> -email-fengchengwen@huawei.com/
>>>
>>>>          sources += files('hns3_rxtx_vec_sve.c')
>>>> +    elif cc.has_argument('-march=armv8.2-a+sve') and
>>>> cc.check_header('arm_sve.h')
>>>> +        sve_cflags = ['-DCC_SVE_SUPPORT']
>>>> +        foreach flag: cflags
>>>> +            # filterout -march -mcpu -mtune
>>>> +            if not (flag.startswith('-march=') or
>>>> + flag.startswith('-mcpu=') or
>>>> flag.startswith('-mtune='))
>>>> +                sve_cflags += flag
>>>> +            endif
>>>> +        endforeach
>>>> +        hns3_sve_lib = static_library('hns3_sve_lib',
>>>> +                        'hns3_rxtx_vec_sve.c',
>>>> +                        dependencies: [static_rte_ethdev],
>>>> +                        include_directories: includes,
>>>> +                        c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>>> +        objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>>>      endif
>>>>  endif
>>>> --
>>>> 2.8.1
>>>
>>>
>>> .
>>>
>