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 1C688A09E4; Tue, 23 Mar 2021 12:22:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 03612140DF1; Tue, 23 Mar 2021 12:22:34 +0100 (CET) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by mails.dpdk.org (Postfix) with ESMTP id 0CFBB140DD7 for ; Tue, 23 Mar 2021 12:22:32 +0100 (CET) Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4F4TRh4nwtznV2p for ; Tue, 23 Mar 2021 19:20:00 +0800 (CST) Received: from [10.67.103.128] (10.67.103.128) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.498.0; Tue, 23 Mar 2021 19:22:21 +0800 To: Ferruh Yigit , fengchengwen , 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: "Min Hu (Connor)" Message-ID: Date: Tue, 23 Mar 2021 19:22:21 +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: 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 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" 在 2021/3/23 18:31, Ferruh Yigit 写道: > 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. OK, v6 has been sent, which fixed all the bugs, please check it, thanks. > >>> >>>> 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 >> > > .