From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3D049A0562; Tue, 23 Mar 2021 11:32:00 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1F8854014D; Tue, 23 Mar 2021 11:32:00 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 2DA5940143 for ; Tue, 23 Mar 2021 11:31:58 +0100 (CET) IronPort-SDR: 2LOq16XbVTqXd7nGzpP2qlte2PtM2o1ns+Inmc9KoGaOhVVvQyBoN71zdpczhZG2Hj0uXJpVa1 oclcRAMVjovg== X-IronPort-AV: E=McAfee;i="6000,8403,9931"; a="210525120" X-IronPort-AV: E=Sophos;i="5.81,271,1610438400"; d="scan'208";a="210525120" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2021 03:31:57 -0700 IronPort-SDR: A9ykHMDVJ3kcGvGx4FGSLoYWJAf022AEP0KPCxFbHZ0/NWRv2n98QHECr1d4bEl1Lk+d2So332 vzbmvIxG5lMg== X-IronPort-AV: E=Sophos;i="5.81,271,1610438400"; d="scan'208";a="604257783" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.14.45]) ([10.252.14.45]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2021 03:31:55 -0700 To: fengchengwen , dev@dpdk.org, "humin29@huawei.com" References: <1615357493-42394-1-git-send-email-humin29@huawei.com> <1616116046-47578-1-git-send-email-humin29@huawei.com> <1616116046-47578-2-git-send-email-humin29@huawei.com> <64b61580-6c58-c7c2-b2f9-d6c3a77d02e1@huawei.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Tue, 23 Mar 2021 10:31:54 +0000 MIME-Version: 1.0 In-Reply-To: <64b61580-6c58-c7c2-b2f9-d6c3a77d02e1@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5 1/8] net/hns3: support runtime config to select IO burst func X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 3/23/2021 3:31 AM, fengchengwen wrote: > > > On 2021/3/22 21:58, Ferruh Yigit wrote: >> On 3/19/2021 1:07 AM, Min Hu (Connor) wrote: >>> From: Chengwen Feng >>> >>> Currently, the driver support multiple IO burst function and auto >>> selection of the most appropriate function based on offload >>> configuration. >>> >>> Most applications such as l2fwd/l3fwd don't provide the means to >>> change offload configuration, so it will use the auto selection's io >>> burst function. >>> >>> This patch support runtime config to select io burst function, which >>> add two config: rx_func_hint and tx_func_hint, both could assign >>> vec/sve/simple/common. >>> >>> The driver will use the following rules to select io burst func: >>> a. if hint equal vec and meet the vec Rx/Tx usage condition then use >>> the neon function. >>> b. if hint equal sve and meet the sve Rx/Tx usage condition then use >>> the sve function. >>> c. if hint equal simple and meet the simple Rx/Tx usage condition then >>> use the simple function. >>> d. if hint equal common then use the common function. >>> e. if hint not set then: >>> e.1. if meet the vec Rx/Tx usage condition then use the neon function. >>> e.2. if meet the simple Rx/Tx usage condition then use the simple >>> function. >>> e.3. else use the common function. >>> >>> Note: the sve Rx/Tx usage condition based on the vec Rx/Tx usage >>> condition and runtime environment (which must support SVE). >>> >>> In the previous versions, driver will preferred use the sve function >>> when meet the sve Rx/Tx usage condition, but in this case driver could >>> get better performance if use the neon function. >>> >> >> Is this saying 'neon' is giving better performance even if 'sve' is supported? > > I'm sorry to confuse you, let me explain the hns3 sve function history: > 1. The sve instruction only support on our latest processor Kunpeng930, and > the sve Rx/Tx function is being gradually optimized. > 2. We define a macro CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE which equal n > default in the original scheme, so driver will not select sve Rx/Tx function > unless user config CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE=y. > 3. We plan to switch CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE equal y when the > sve Rx/Tx function is fully optimized. > 4. The makefile is switched to meson build in 20.11, and it's not recommended > to define the marco such as above, so the upload scheme is adjusted which > delete the macro CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE, this leads to driver > select sve Rx/Tx function when meeting sve conditions (which are gcc support > compile sve and the host cpu&os support sve), but it doesn't fit out plan, so > here we modify it. > Got it, so you want keep the 'neon' path default until 'sve' path is more optimized, thanks for clarification. >> >>> Signed-off-by: Chengwen Feng >>> Signed-off-by: Min Hu (Connor) >>> --- >>> v6: >>> - document hns3.rst about description of vec, common and simple. >>> --- >>>   doc/guides/nics/hns3.rst               | 19 +++++++++ >>>   doc/guides/rel_notes/release_21_05.rst |  1 + >>>   drivers/net/hns3/hns3_ethdev.c         | 77 ++++++++++++++++++++++++++++++++++ >>>   drivers/net/hns3/hns3_ethdev.h         | 15 +++++++ >>>   drivers/net/hns3/hns3_ethdev_vf.c      |  4 ++ >>>   drivers/net/hns3/hns3_rxtx.c           | 54 +++++++++++++++++------- >>>   6 files changed, 156 insertions(+), 14 deletions(-) >>> >>> diff --git a/doc/guides/nics/hns3.rst b/doc/guides/nics/hns3.rst >>> index 84bd7a3..8f48240 100644 >>> --- a/doc/guides/nics/hns3.rst >>> +++ b/doc/guides/nics/hns3.rst >>> @@ -46,6 +46,25 @@ Prerequisites >>>   - Follow the DPDK :ref:`Getting Started Guide for Linux ` to setup the basic DPDK environment. >>>     +Runtime Config Options >>> +---------------------- >>> + >>> +- ``rx_func_hint`` (default ``none``) >>> + >>> +  Used to select Rx burst function, supported value are "vec", "sve", "simple", "common". >> >> ``vec``, ``sve``, ``simple`` and ``common``. ?? >> >>> +  When equal "vec" and meet the vector Rx usage condition then use the default vector Rx implementation, 'neon' for Kunpeng Arm platform. >>> +  When equal "sve" and meet the sve Rx usage condition then use the sve Rx function. >>> +  When equal "simple" and meet the simple Rx usage condition then use the simple Rx function which indicates the Scalar algorithm obtained from rte_eth_rx_burst_mode_get. >>> +  When equal "common" then use the common Rx function which indicates the Scalar Scattered algorithm obtained from rte_eth_rx_burst_mode_get. >>> + >> >> A few comments on the documentation, >> >> - What about using `` to highlight the parameter, like ``vec``, on all occurrences. >> >> - What about adding bullet points for each parameter >> >> - I think you can drop "When equal" start from all >> >> - You can drop "obtained from rte_eth_rx_burst_mode_get" part, the function name is not needed here, something like gives same information: >> >> - Can "and meet the vector Rx usage condition" be simplified, overall what about something like: >> * ``simple``, if supported use the ``simple`` Rx function which indicates the scalar algorithm. >> >> - It is not clear what happens when provided parameter is not supported, like when I set 'vec' but if PMD doesn't support it, which function will be supported? >> >> - Can you please try to limit the line length aroung 80 columns. >> >> - No need to start words with uppercase for 'Scalar' & 'Scalar Scattered' >> >> - Same for below Tx ones. >> >> . > > OK, will fix in later patch >