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 99A5FA00C2; Wed, 17 Mar 2021 16:28:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 45C2D4067E; Wed, 17 Mar 2021 16:28:46 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 1D87F4014D for ; Wed, 17 Mar 2021 16:28:43 +0100 (CET) IronPort-SDR: qhe6vIogKhDPVaWcLr/jFvXJIXQrRf758/i/uk19/VSswKz66e/806orD5QjAO81UW2mvVqqQh ZCK0weqMSQSA== X-IronPort-AV: E=McAfee;i="6000,8403,9926"; a="250844244" X-IronPort-AV: E=Sophos;i="5.81,256,1610438400"; d="scan'208";a="250844244" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2021 08:28:42 -0700 IronPort-SDR: euZpL3eHcS3I9486Kxowdw55onWZse0uQfR+Im6VGwc7hKGBTDHFBCcy6y0Of9OdysQGxRYBn5 eu3R2/IY5F+A== X-IronPort-AV: E=Sophos;i="5.81,256,1610438400"; d="scan'208";a="405972656" Received: from mmansoor-mobl.ger.corp.intel.com (HELO [10.252.22.40]) ([10.252.22.40]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2021 08:28:42 -0700 To: "Min Hu (Connor)" References: <1615356985-24722-1-git-send-email-humin29@huawei.com> <1615549872-49720-1-git-send-email-humin29@huawei.com> <1615549872-49720-2-git-send-email-humin29@huawei.com> <80c7ed02-5f57-fb39-a5e9-6e7dbdcc3c3d@intel.com> <0ecb9115-11b1-2d3f-b333-3e6b7b8b7a6e@huawei.com> From: Ferruh Yigit Cc: dev@dpdk.org X-User: ferruhy Message-ID: <36c10c8a-034d-1883-4d2a-5f9c13d92c32@intel.com> Date: Wed, 17 Mar 2021 15:28:38 +0000 MIME-Version: 1.0 In-Reply-To: <0ecb9115-11b1-2d3f-b333-3e6b7b8b7a6e@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 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/17/2021 1:14 AM, Min Hu (Connor) wrote: > > > 在 2021/3/16 20:40, Ferruh Yigit 写道: >> On 3/12/2021 11:51 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. >>> >>> Signed-off-by: Chengwen Feng >>> Signed-off-by: Min Hu (Connor) >>> --- >>>   doc/guides/nics/hns3.rst               | 20 +++++++++ >>>   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, 157 insertions(+), 14 deletions(-) >>> >>> diff --git a/doc/guides/nics/hns3.rst b/doc/guides/nics/hns3.rst >>> index 84bd7a3..40d2e3b 100644 >>> --- a/doc/guides/nics/hns3.rst >>> +++ b/doc/guides/nics/hns3.rst >>> @@ -46,6 +46,26 @@ 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". >>> +  When equal "vec" and meet the vector Rx usage condition then use the neon >>> Rx function. >>> +  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. >>> +  When equal "common" then use the common Rx function. >>> + >>> +- ``tx_func_hint`` (default ``none``) >>> + >>> +  Used to select Tx burst function, supported value are "vec", "sve", >>> "simple", "common". >>> +  When equal "vec" and meet the vector Tx usage condition then use the neon >>> Tx function. >>> +  When equal "sve" and meet the sve Tx usage condition then use the sve Tx >>> function. >>> +  When equal "simple" and meet the simple Tx usage condition then use the >>> simple Tx function. >>> +  When equal "common" then use the common Tx function. >>> + >> >> I think 'vec' & 'sve' are more self explenatory, but can you please describe >> what is 'common' and 'simple', and the difference of these two? > In the Rx direction, simple indicates that the Scalar algorithm obtained from > rte_eth_rx_burst_mode_get, and common indicates that the Scalar Scattered > algorithm obtained from rte_eth_rx_burst_mode_get. > > In the TX direction, simple indicates that the Scalar Simple algorithm in the > rte_eth_tx_burst_mode_get, and common indicates that the Scalar algorithm > obtained in the rte_eth_tx_burst_mode_get. > Got it, can you please document what you described above in this document? > Later, we will send a patch to modify the names obtained in > rte_eth_rx_burst_mode_get, that is, the original Scalar is renamed Scalar Simple > and Scalar Scattered is renamed Scalar. The Rx and Tx are not in correspondence, > which may leads to misunderstanding. > >> >> btw, since both 'neon' and 'sve' are vector implementations, what do you think >> to have arguments as 'neon' & 'sve', instead of 'vec' & 'sve'? > 'vec' here means the default vector type in the current platform(In future, we > will support NIC in different kinds of platform). when the DPDK run on different > platform, the default vector will be different. For instance, now in ARM soc, > 'vec' means 'neon', in X86 platform, 'vec' > means 'SSE/AVX' or others. > I see, again can you document this above, in document for 'vec' it says "use the neon", instead it can say something like "use default vector implementation, 'neon' for Arm" ... Btw, I can see v4 sent, but there is no changelog, and documentation seems same, what has changed there?