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 B8CB3A054F; Wed, 17 Mar 2021 02:15:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61C1240689; Wed, 17 Mar 2021 02:15:04 +0100 (CET) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id CA69F40040 for ; Wed, 17 Mar 2021 02:15:01 +0100 (CET) Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4F0XGB6NdlzrXZV for ; Wed, 17 Mar 2021 09:13:06 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Wed, 17 Mar 2021 09:14:54 +0800 To: Ferruh Yigit , 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> From: "Min Hu (Connor)" Message-ID: <0ecb9115-11b1-2d3f-b333-3e6b7b8b7a6e@huawei.com> Date: Wed, 17 Mar 2021 09:14:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <80c7ed02-5f57-fb39-a5e9-6e7dbdcc3c3d@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.128] X-CFilter-Loop: Reflected 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" 在 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. 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. thanks > .