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 772FBA0C4E; Tue, 2 Nov 2021 15:19:44 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 66C2F41139; Tue, 2 Nov 2021 15:19:44 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id E948E4068F for ; Tue, 2 Nov 2021 15:19:42 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10155"; a="231123069" X-IronPort-AV: E=Sophos;i="5.87,203,1631602800"; d="scan'208";a="231123069" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Nov 2021 07:19:42 -0700 X-IronPort-AV: E=Sophos;i="5.87,203,1631602800"; d="scan'208";a="489126691" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.3.189]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 02 Nov 2021 07:19:40 -0700 Date: Tue, 2 Nov 2021 14:19:32 +0000 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: Ben Magistro , "dev@dpdk.org" Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] Overriding rte_config.h 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 Tue, Nov 02, 2021 at 12:24:43PM +0000, Ananyev, Konstantin wrote: > > > > > On Fri, Oct 29, 2021 at 09:48:30AM -0400, Ben Magistro wrote: > > > > > With the transition to meson, what is the best way to provide custom values > > > > > to parameters in rte_config.h? When using makefiles, (from memory, I > > > > > think) we used common_base as a template that was copied in as a > > > > > replacement for defconfig_x86.... Our current thinking is to apply a > > > > > locally maintained patch so that we can track custom values easier to the > > > > > rte_config.h file unless there is another way to pass in an overridden > > > > > value. As an example, one of the values we are customizing is > > > > > IP_FRAG_MAX_FRAG. > > > > > > > > > > Cheers, > > > > > > > > > There is no one defined way for overriding values in rte_config with the > > > > meson build system, as values there are ones that should rarely need to be > > > > overridden. If it's the case that one does need tuning, we generally want > > > > to look to either change the default so it works for everyone, or > > > > alternatively look to replace it with a runtime option. > > > > > > > > In the absense of that, a locally maintained patch may be reasonable. To > > > > what value do you want to change MAX_FRAG? Would it be worth considering as > > > > a newer default value in DPDK itself, since the current default is fairly > > > > low? > > > > > > That might be an option, with IP_FRAG_MAX_FRAG==8 it should be able > > > to cover common jumbo frame size (9K) pretty easily. > > > As a drawback default reassembly table size will double. > > > > Maybe not. I'm not an expert in the library, but it seems the basic struct > > used for tracking the packets and fragments is "struct ip_frag_pkt". Due to > > the other data in the struct and the linked-list overheads, the actual size > > increase when doubling MAX_FRAG from 4 to 8 is only 25%. According to gdb > > on my debug build it goes from 192B to 256B. > > Ah yes, you right, struct ip_frag should fit into 16B, key seems the biggest one. > > > > > > Even better would be to go a step further and rework lib/ip_frag > > > to make it configurable runtime parameter. > > > > > Agree. However, that's not as quick a fix as just increasing the default > > max segs value which could be done immediately if there is consensus on it. > > You mean for 21.11? > I don't mind in principle, but would like to know other people thoughts here. > Another thing - we didn't announce it in advance, and it is definitely an ABI change. I notice from this patch you submitted that the main structure in question is being hidden[1]. Will it still be an ABI change if that patch is merged in? Alternatively, should a fragment count increase be considered as part of that change? /Bruce [1] http://patches.dpdk.org/project/dpdk/patch/20211101124915.9640-1-konstantin.ananyev@intel.com/