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 3E408A056A; Thu, 11 Mar 2021 18:32:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B5E4D406A3; Thu, 11 Mar 2021 18:32:03 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id B33F64014D for ; Thu, 11 Mar 2021 18:32:02 +0100 (CET) IronPort-SDR: KtWJimM0ifFMquslNdMptuCT1+ZwbpnHspMnpeaa4ftHv8VnLKCvwVHDSkCc7hVjkv6i/quSJF Z/fMjApy7N1g== X-IronPort-AV: E=McAfee;i="6000,8403,9920"; a="188070922" X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208";a="188070922" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2021 09:31:45 -0800 IronPort-SDR: CHVO4pqWc1ZmuqAuyOY3JgQ9iTMEc9Uh1o/4nzC1L6vmazITR08eUY1bSg712OG7zv0oBqM7ka L2od8BQFN5Pg== X-IronPort-AV: E=Sophos;i="5.81,241,1610438400"; d="scan'208";a="448350683" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.22.78]) ([10.252.22.78]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2021 09:31:44 -0800 To: "Min Hu (Connor)" , dev@dpdk.org References: <1615356985-24722-1-git-send-email-humin29@huawei.com> <1615356985-24722-2-git-send-email-humin29@huawei.com> From: Ferruh Yigit Cc: Ciara Power , David Marchand X-User: ferruhy Message-ID: Date: Thu, 11 Mar 2021 17:31:36 +0000 MIME-Version: 1.0 In-Reply-To: <1615356985-24722-2-git-send-email-humin29@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2 1/9] 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/10/2021 6:16 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/rel_notes/release_21_05.rst | 1 + > drivers/net/hns3/hns3_ethdev.c | 74 ++++++++++++++++++++++++++++++++++ > drivers/net/hns3/hns3_ethdev.h | 12 ++++++ > drivers/net/hns3/hns3_ethdev_vf.c | 1 + > drivers/net/hns3/hns3_rxtx.c | 54 ++++++++++++++++++------- > 5 files changed, 128 insertions(+), 14 deletions(-) > Hi Connor, There are two recently added APIs to enable user to select vector datapath: 'rte_vect_set_max_simd_bitwidth()' 'rte_vect_get_max_simd_bitwidth()' Also there is an eal parameter around those APIs: '--force-max-simd-bitwidth' I wonder these existing APIs can be utilized to select the vector path instead of adding device args to the PMD, can you please check? Thanks, ferruh