From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id ADF8DA04B5; Thu, 29 Oct 2020 22:27:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 21B27CA18; Thu, 29 Oct 2020 22:27:31 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by dpdk.org (Postfix) with ESMTP id 79B24CA16 for ; Thu, 29 Oct 2020 22:27:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604006847; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rx1231L19mbSFALrsTsxp8dUVQfJWN3WD94XZ9HsB/s=; b=PAJf8KASsI1SMWKGrB77WqqpyAD+FTp/zPPSa3YvBBMbQ+YML7N6X4Oz1KNXjDiN/9rcg5 igQ6gZ7W0t9KlstrZ9gOXImX4d8isSW2i66EPXmtOB58hnlDjfc0+5odsQ1bo8+BDxPL5B wSKr+RTqxi9Z/JjkJhdb56kYfC+tB8Q= Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-468-BSjlWqCZNvCRhcI4zZ7Ghw-1; Thu, 29 Oct 2020 17:27:25 -0400 X-MC-Unique: BSjlWqCZNvCRhcI4zZ7Ghw-1 Received: by mail-vs1-f70.google.com with SMTP id j190so1117122vsc.0 for ; Thu, 29 Oct 2020 14:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rx1231L19mbSFALrsTsxp8dUVQfJWN3WD94XZ9HsB/s=; b=sw5gRJy/Y90qDzBMPS8QBMTq9UG01Z1UKKqwVh6W58Le5umbH8nZcMq2UXzm9tT1vO arHaT05m7B7aVQMqhOOS5OF1uzjT+yoZ4XDaKvbs9Mtzd4herdy6liDjl6EowimH60zV 9O2f/H33Jk91iu5oR7HYKN+nNs8zoZsT7oQkpmI39p7/1CVRRUX1ZVzisxuQ3plgRQhH 1ANcCzOx7x1z+xKV1VgZ0M3AeoZ5zSZmF9R9a4HZhN5Nv+TuYp/Jnnfx8Yo/do9L9zR7 K8efuEgIa4sWQDCmUnHwNLVJB/+MTZXbcK7Jyp24OSatich7Us0uIXiYRuRnWInRR9OP MBBg== X-Gm-Message-State: AOAM533ZZqjpNoCma58FN+UDLQG51uKW+67dCokYaFU6WU0Ev5y+NSKv aJ1VZQWwnoncqHXtgwP3jfklRGaLVvFZKzMLyfuUm1nv/d85JnqSYDtYKQXSizgOmNVhZZipHfm BBXCtji0Ix6M4CSbrlxQ= X-Received: by 2002:a67:2fca:: with SMTP id v193mr5531046vsv.18.1604006844618; Thu, 29 Oct 2020 14:27:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+jPZusDJnC7HmIBoTYp3+8ghBgCPOwUKjnvJAlnTly0lH4mWO4o/SFs8EfVgmJRCOaQpSu7SLvTsOwo5TChs= X-Received: by 2002:a67:2fca:: with SMTP id v193mr5531017vsv.18.1604006844349; Thu, 29 Oct 2020 14:27:24 -0700 (PDT) MIME-Version: 1.0 References: <1603494392-7181-1-git-send-email-liang.j.ma@intel.com> <1603810749-22285-1-git-send-email-liang.j.ma@intel.com> <1603810749-22285-4-git-send-email-liang.j.ma@intel.com> In-Reply-To: <1603810749-22285-4-git-send-email-liang.j.ma@intel.com> From: David Marchand Date: Thu, 29 Oct 2020 22:27:13 +0100 Message-ID: To: Liang Ma Cc: dev , "Ruifeng Wang (Arm Technology China)" , "Wang, Haiyue" , Bruce Richardson , "Ananyev, Konstantin" , David Hunt , Jerin Jacob , Neil Horman , Thomas Monjalon , Timothy McDaniel , Gage Eads , Marcin Wojtas , Guy Tzalik , Ajit Khaparde , Harman Kalra , John Daley , "Wei Hu (Xavier)" , Ziyang Xuan , Matan Azrad , Yong Wang , Anatoly Burakov , Jerin Jacob , Jan Viktorin , David Christensen , Ray Kinsella Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v10 3/9] eal: add intrinsics support check infrastructure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Oct 27, 2020 at 4:00 PM Liang Ma wrote: > > Currently, it is not possible to check support for intrinsics that > are platform-specific, cannot be abstracted in a generic way, or do not > have support on all architectures. The CPUID flags can be used to some > extent, but they are only defined for their platform, while intrinsics > will be available to all code as they are in generic headers. > > This patch introduces infrastructure to check support for certain > platform-specific intrinsics, and adds support for checking support for > IA power management-related intrinsics for UMWAIT/UMONITOR and TPAUSE. > > Signed-off-by: Anatoly Burakov > Signed-off-by: Liang Ma > Acked-by: David Christensen > Acked-by: Jerin Jacob > Acked-by: Ruifeng Wang > Acked-by: Ray Kinsella Coming late to the party, it seems crowded... > diff --git a/lib/librte_eal/include/generic/rte_cpuflags.h b/lib/librte_eal/include/generic/rte_cpuflags.h > index 872f0ebe3e..28a5aecde8 100644 > --- a/lib/librte_eal/include/generic/rte_cpuflags.h > +++ b/lib/librte_eal/include/generic/rte_cpuflags.h > @@ -13,6 +13,32 @@ > #include "rte_common.h" > #include > > +#include > + > +/** > + * Structure used to describe platform-specific intrinsics that may or may not > + * be supported at runtime. > + */ > +struct rte_cpu_intrinsics { > + uint32_t power_monitor : 1; > + /**< indicates support for rte_power_monitor function */ > + uint32_t power_pause : 1; > + /**< indicates support for rte_power_pause function */ > +}; - The rte_power library is supposed to be built on top of cpuflags. Not the other way around. Those capabilities should have been kept inside the rte_power_ API and not pollute the cpuflags API. - All of this should have come as a single patch as the previously introduced API is unusable before. > + > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice > + * > + * Check CPU support for various intrinsics at runtime. > + * > + * @param intrinsics > + * Pointer to a structure to be filled. > + */ > +__rte_experimental > +void > +rte_cpu_get_intrinsics_support(struct rte_cpu_intrinsics *intrinsics); > + > /** > * Enumeration of all CPU features supported > */ > diff --git a/lib/librte_eal/include/generic/rte_power_intrinsics.h b/lib/librte_eal/include/generic/rte_power_intrinsics.h > index fb897d9060..03a326f076 100644 > --- a/lib/librte_eal/include/generic/rte_power_intrinsics.h > +++ b/lib/librte_eal/include/generic/rte_power_intrinsics.h > @@ -32,6 +32,10 @@ > * checked against the expected value, and if they match, the entering of > * optimized power state may be aborted. > * > + * @warning It is responsibility of the user to check if this function is > + * supported at runtime using `rte_cpu_get_features()` API call. Failing to do > + * so may result in an illegal CPU instruction error. > + * - Reading this API description... what am I supposed to do in my application or driver who wants to use the new rte_power_monitor/rte_power_pause stuff? I should call rte_cpu_get_features(TOTO) ? This comment does not give a hint. I suppose the intent was to refer to the rte_cpu_get_intrinsics_support() thing. This must be fixed. - Again, I wonder why we are exposing all this stuff. This should be hidden in the rte_power API. -- David Marchand