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 8327BA04B9; Mon, 7 Sep 2020 10:44:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 69EDE2BAB; Mon, 7 Sep 2020 10:44:36 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id E84641DB8 for ; Mon, 7 Sep 2020 10:44:34 +0200 (CEST) IronPort-SDR: /GAR2ZW2VIEM4j5DpaTiD+WbSG67gvYn6aN3JsrEa/Gpa0r8EpR3mt8Y2zOK9/UCg314H3UZBa xVkQ2gxS1UZw== X-IronPort-AV: E=McAfee;i="6000,8403,9736"; a="137490775" X-IronPort-AV: E=Sophos;i="5.76,401,1592895600"; d="scan'208";a="137490775" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2020 01:44:34 -0700 IronPort-SDR: RKHZQGn3iiD9diDxaVTyxm5z7rvPJqe06Dv44W15GzhuLhDajpC+gOucu7Okr7abXfN0nu0Vwy w/3JYQswLY2A== X-IronPort-AV: E=Sophos;i="5.76,401,1592895600"; d="scan'208";a="479569841" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.80.24]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 07 Sep 2020 01:44:32 -0700 Date: Mon, 7 Sep 2020 09:44:28 +0100 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: "Power, Ciara" , "dev@dpdk.org" , "Burakov, Anatoly" , "Mcnamara, John" , "Kovacevic, Marko" Message-ID: <20200907084428.GB312@bricha3-MOBL.ger.corp.intel.com> References: <20200807155859.63888-1-ciara.power@intel.com> <20200827161304.32300-1-ciara.power@intel.com> <20200827161304.32300-4-ciara.power@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2 03/17] doc: add detail on using max SIMD bitwidth 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 Sun, Sep 06, 2020 at 10:20:30PM +0000, Ananyev, Konstantin wrote: > > This patch adds documentation on the usage of the max SIMD bitwidth EAL > > setting, and how to use it to enable AVX-512 at runtime. > > > > Cc: Anatoly Burakov > > Cc: John McNamara > > Cc: Marko Kovacevic > > > > Signed-off-by: Ciara Power > > --- > > doc/guides/howto/avx512.rst | 36 +++++++++++++++++++ > > doc/guides/linux_gsg/eal_args.include.rst | 12 +++++++ > > .../prog_guide/env_abstraction_layer.rst | 31 ++++++++++++++++ > > 3 files changed, 79 insertions(+) > > create mode 100644 doc/guides/howto/avx512.rst > > > > diff --git a/doc/guides/howto/avx512.rst b/doc/guides/howto/avx512.rst > > new file mode 100644 > > index 0000000000..ebae0f2b4f > > --- /dev/null > > +++ b/doc/guides/howto/avx512.rst > > @@ -0,0 +1,36 @@ > > +.. SPDX-License-Identifier: BSD-3-Clause > > + Copyright(c) 2020 Intel Corporation. > > + > > + > > +Using AVX-512 with DPDK > > +======================= > > + > > +AVX-512 is not used by default in DPDK, but it can be selected at runtime by apps through the use of EAL API, > > +and by the user with a commandline argument. DPDK has a setting for max SIMD bitwidth, > > +which can be modified and will then limit the vector path taken by the code. > > It's is a good idea to have such ability, > though just one global variable for all DPDK lib/drivers > seems a bit coarse to me. > Let say we have 2 libs: libA and libB. > Both do have RTE_MAX_512_SIMD specific code-path, > though libA would cause frequency level change, while libB wouldn't. > So user (to avoid frequency level change) would have to block > 512_SIMD for both libs. > I think it would be much better to follow the strategy we use for log-level: > there is a global simd_width, but each DDPK entity (lib/driver) also has > it's own simd_width that overrules a global one (more fine-grained control). That for me is a nightmare scenario. How is the user meant to know what libs could cause him a frequency or not, or is he meant to determine that empirically by trial and error on each platform? This scenario is completely unlike logging in that it's non-obvious to the user, and so needs to be kept as consumable as possible to the app-developer and the user. Unless we find a concrete scenario where having a single switch is causing real user problems, I'd much rather keep things simple. See also answer below, where I point out that the main target of this is developers, who can use this flag to indicate what vector bitwidth their app uses, and then allow DPDK to match that. > > > + > > + > > +Using the API in apps > > +--------------------- > > + > > +Apps can request DPDK uses AVX-512 at runtime, if it provides improved application performance. > > +This can be done by modifying the EAL setting for max SIMD bitwidth to 512, as by default it is 256, > > +which does not allow for AVX-512. > > + > > +.. code-block:: c > > + > > + rte_set_max_simd_bitwidth(RTE_MAX_512_SIMD); > > + > > +This API should only be called once at initialization, before EAL init. > > If the only possible usage scenario for that function is init time before EAL init, > then do we really need it at all? > As we have cmd-line flag anyway? > User can achieve similar goal, by just: rte_eal_init(,..."--force-max-simd-bitwidth=..."...); Ideally, the user should never know or care about the cmdline flag, it's only for testing. The main criteria for allowing DPDK to use longer instruction sets is whether the application itself will similarly use them, and that's something for the programmer to do. Having the programmer muck about with cmdline arguments is less than ideal, so a proper API is warrented here. The reason for the note about EAL init, is that we don't want libraries to have to check the max bitwidth each time an API is called, so we want to have a way to prevent people changing things at runtime. This therefore seemed simplest. /Bruce