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 95159A0A02; Tue, 27 Apr 2021 15:46:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0DA25406A3; Tue, 27 Apr 2021 15:46:52 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 9ED7F4014E for ; Tue, 27 Apr 2021 15:46:49 +0200 (CEST) IronPort-SDR: pvxVUV3dTYPJIfvnAKODVES72eiA/x2Uy8G+Wsc0xwpPiWJAw7u7Qfzh2vbJuqMzZifdXbkSOz UZAvXR4VR08A== X-IronPort-AV: E=McAfee;i="6200,9189,9966"; a="183991543" X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="183991543" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 06:46:47 -0700 IronPort-SDR: evEpPHGl8xu/BrMrlZ0sSQbEDDIuXEbN2n29ZUBQFpgqdM312QQ0Bzgq1B4U19wshXoOY4QPzX /9PD6hFdWpFw== X-IronPort-AV: E=Sophos;i="5.82,254,1613462400"; d="scan'208";a="457650556" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.221.231]) ([10.213.221.231]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Apr 2021 06:46:46 -0700 To: "Min Hu (Connor)" , dev@dpdk.org References: <1619408092-54050-1-git-send-email-humin29@huawei.com> <1619408092-54050-7-git-send-email-humin29@huawei.com> From: Ferruh Yigit X-User: ferruhy Message-ID: Date: Tue, 27 Apr 2021 14:46:42 +0100 MIME-Version: 1.0 In-Reply-To: <1619408092-54050-7-git-send-email-humin29@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 6/6] net/hns3: fix vector Rx burst default value 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 4/26/2021 4:34 AM, Min Hu (Connor) wrote: > From: Chengwen Feng > > Currently, driver uses the macro HNS3_DEFAULT_RX_BURST whose value is > 32 to limit the vector Rx burst size, as a result, the burst size user > configure can't exceed 32. > > This patch fixes this problem by defining the macro > HNS3_DEFAULT_RX_BURST as 64. > > Fixes: a3d4f4d291d7 ("net/hns3: support NEON Rx") > Cc: stable@dpdk.org > > Signed-off-by: Chengwen Feng > Signed-off-by: Min Hu (Connor) > --- > drivers/net/hns3/hns3_rxtx.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h > index 1e2e994..ba24e00 100644 > --- a/drivers/net/hns3/hns3_rxtx.h > +++ b/drivers/net/hns3/hns3_rxtx.h > @@ -20,7 +20,7 @@ > #define HNS3_DEFAULT_TX_RS_THRESH 32 > #define HNS3_TX_FAST_FREE_AHEAD 64 > > -#define HNS3_DEFAULT_RX_BURST 32 > +#define HNS3_DEFAULT_RX_BURST 64 It seems in the vector Rx path, the number of receive packets are limited silently to 'HNS3_DEFAULT_RX_BURST' independent from what user requested/configured. There can be driver/HW limitations to 'HNS3_DEFAULT_RX_BURST' that is OK, but instead of limiting user request, what do you think about Rx in the 'HNS3_DEFAULT_RX_BURST' blocks until user request justified? I mean something like following implementation: https://git.dpdk.org/dpdk/commit/?id=d96394ea263c