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 23612A034F; Mon, 22 Mar 2021 15:03:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9589A40042; Mon, 22 Mar 2021 15:03:12 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id E334840040 for ; Mon, 22 Mar 2021 15:03:10 +0100 (CET) IronPort-SDR: O+ZIDY26ECa7T8RHOVlo2sCGwwRY5KSkzgSGnTvl9MgCR1eb7LiyLUr9Qiss5WFkg/zzh2XueA AAnKzhYnOgpw== X-IronPort-AV: E=McAfee;i="6000,8403,9931"; a="190370667" X-IronPort-AV: E=Sophos;i="5.81,269,1610438400"; d="scan'208";a="190370667" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2021 07:03:09 -0700 IronPort-SDR: tjsSazHN1qm6PzTOwPQVOWrW0+bHrPpSbGvjO4s3P5uAXBL5g5KXFgj1vI3ayzvkwW0RFTif+G ouWYTN3CN1YA== X-IronPort-AV: E=Sophos;i="5.81,269,1610438400"; d="scan'208";a="451747509" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.14.44]) ([10.252.14.44]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2021 07:03:09 -0700 From: Ferruh Yigit To: "Min Hu (Connor)" , dev@dpdk.org 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> X-User: ferruhy Message-ID: <99e367b9-60fe-3cb9-5647-d2bc00b3ed0e@intel.com> Date: Mon, 22 Mar 2021 14:03:07 +0000 MIME-Version: 1.0 In-Reply-To: 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/22/2021 1:58 PM, 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? > >> 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. Can you also put a separate line to document the Rx function selection order if the ``rx_func_hint`` is not provided. Same for Tx.