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 2EF68A055D; Wed, 3 Mar 2021 16:38:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 546211606F7; Wed, 3 Mar 2021 16:38:20 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id E8B9440683 for ; Wed, 3 Mar 2021 16:38:18 +0100 (CET) IronPort-SDR: 6DKkGg8TbXCmV8J1UAznsQD3SCeeMP2A2bmbYD1E6SKPDaf3uNXcUozFBp56hxj0ncawCNFtzb HsVZKUAa5OHQ== X-IronPort-AV: E=McAfee;i="6000,8403,9912"; a="174857090" X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="174857090" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 07:38:17 -0800 IronPort-SDR: aw93AITlViSsu8drXYekPsBNlvZd5QHYF99Q0hLcNgr/v1sj/J9lYFVVCPH6kv5xxTAcaJrzl1 HVwPY1VL06Bw== X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="506830604" Received: from bonniec-mobl.ger.corp.intel.com (HELO [10.252.9.23]) ([10.252.9.23]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 07:38:16 -0800 To: "Loftus, Ciara" Cc: "dev@dpdk.org" References: <20210218092307.29575-1-ciara.loftus@intel.com> <20210224111852.11947-1-ciara.loftus@intel.com> <20210224111852.11947-2-ciara.loftus@intel.com> <0a0f4b3cde6348cfaf343b2457462403@intel.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <7acd6f03-4522-a79e-5899-240953d64aec@intel.com> Date: Wed, 3 Mar 2021 15:38:13 +0000 MIME-Version: 1.0 In-Reply-To: <0a0f4b3cde6348cfaf343b2457462403@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 1/3] net/af_xdp: Increase max batch size to 512 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/3/2021 3:07 PM, Loftus, Ciara wrote: >> >> On 2/24/2021 11:18 AM, Ciara Loftus wrote: >>> Prior to this the max size was 32 which was unnecessarily >>> small. >> >> Can you please describe the impact? Why changed from 32 to 512? >> I assume this is to improve the performance but can you please explicitly >> document it in the commit log? > > Indeed - improved performance due to bulk operations and fewer ring accesses and syscalls. > The value 512 was arbitrary. I will change this to the default ring size as defined by libbpf (2048) in v2. > Will update the commit log with this info. > >> >>> Also enforce the max batch size for TX for both >>> copy and zero copy modes. Prior to this only copy mode >>> enforced the max size. >>> >> >> By enforcing, the PMD ignores the user provided burst value if it is more than >> PMS supported MAX, and this ignoring is done in silent. Also there is no way >> to >> discover this MAX value without checking the code. >> >> Overall, why this max values are required at all? After quick check I can see >> they are used for some bulk operations, which I assume can be eliminated, >> what >> do you think? > > We need to size some arrays at compile time with this max value. > > Instead of removing the bulk operations which may impact performance, how about taking an approach where we split batches that are > 2048 into smaller batches and still handle all the packets instead of discarding those > 2048. Something like what's done in ixgbe for example: > http://code.dpdk.org/dpdk/v21.02/source/drivers/net/ixgbe/ixgbe_rxtx.c#L318 >` If there is no reasonable way to eliminate the fix sized arrays, above suggestion looks good. Thanks, ferruh