From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 9BA91A04DC;
Tue, 20 Oct 2020 16:01:21 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 4354EBBCA;
Tue, 20 Oct 2020 16:01:19 +0200 (CEST)
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id A6954BBCA
for <dev@dpdk.org>; Tue, 20 Oct 2020 16:01:16 +0200 (CEST)
IronPort-SDR: /qj2364/Qm75cZCZd1nMspkw3lLVtJYdt1BcrZTA2eJoW03I9YolmDSBGtdAWI7QFtLVxbOWN1
WzkcsKoswO4g==
X-IronPort-AV: E=McAfee;i="6000,8403,9779"; a="184839258"
X-IronPort-AV: E=Sophos;i="5.77,397,1596524400"; d="scan'208";a="184839258"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38])
by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
20 Oct 2020 07:01:13 -0700
IronPort-SDR: XdfULEtr/8SqVIQEecrvoYi4k8e9oCa0GlwMOxAnEdt0ahNncYmyNjBzm7w7xkBT3gRev3C/ae
4eWa129zhPvA==
X-IronPort-AV: E=Sophos;i="5.77,397,1596524400"; d="scan'208";a="465937395"
Received: from dhunt5-mobl5.ger.corp.intel.com (HELO [10.252.3.168])
([10.252.3.168])
by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
20 Oct 2020 07:01:09 -0700
To: Thomas Monjalon <thomas@monjalon.net>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Ruifeng Wang <Ruifeng.Wang@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Liang Ma <liang.j.ma@intel.com>,
Jan Viktorin <viktorin@rehivetech.com>,
David Christensen <drc@linux.vnet.ibm.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
"timothy.mcdaniel@intel.com" <timothy.mcdaniel@intel.com>,
"gage.eads@intel.com" <gage.eads@intel.com>,
"chris.macnamara@intel.com" <chris.macnamara@intel.com>,
Anatoly Burakov <anatoly.burakov@intel.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>, nd <nd@arm.com>
References: <da3fe4e5bbe976882c56a71d20a9055c1600e6aa.1602763439.git.anatoly.burakov@intel.com>
<2164670.uy6Bi0JdNo@thomas>
<VI1PR0802MB2351FB5DC59406DF6A82C41D9E1F0@VI1PR0802MB2351.eurprd08.prod.outlook.com>
<7898621.PryZgIvODB@thomas>
From: David Hunt <david.hunt@intel.com>
Message-ID: <73102e35-00d3-fb5e-0169-ba7015880ed8@intel.com>
Date: Tue, 20 Oct 2020 15:01:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <7898621.PryZgIvODB@thomas>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [dpdk-dev] [PATCH v7 02/10] eal: add power management intrinsics
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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 20/10/2020 8:35 AM, Thomas Monjalon wrote:
> 20/10/2020 04:49, Ruifeng Wang:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 15/10/2020 14:04, Anatoly Burakov:
>>>> +/**
>>>> + * This function is not supported on ARM.
>>>> + */
>>>> +static inline void
>>>> +rte_power_monitor(const volatile void *p, const uint64_t
>>> expected_value,
>>>> + const uint64_t value_mask, const uint64_t tsc_timestamp,
>>>> + const uint8_t data_sz) {
>>>> + RTE_SET_USED(p);
>>>> + RTE_SET_USED(expected_value);
>>>> + RTE_SET_USED(value_mask);
>>>> + RTE_SET_USED(tsc_timestamp);
>>>> + RTE_SET_USED(data_sz);
>>>> +}
>>> Are you sure it cannot be partially supported with WFE instruction?
>>>
>> Armv8 WFE instruction can support monitoring of specific address for changes,
>> but not monitoring of TSC timestamp.
> So it is a partial support.
>
> We must try hard to unify architectures support
> to avoid #ifdef everywhere.
>
> I don't agree with how are managed new instructions recently.
> Please look further.
>
Hi Thomas,
We believe this is ready for -rc1, can we discuss this with the
technical board before the RC1 tag is applied?
Regards,
Dave.