From: Bruce Richardson <bruce.richardson@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Ben Magistro <koncept1@gmail.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Overriding rte_config.h
Date: Tue, 2 Nov 2021 14:19:32 +0000 [thread overview]
Message-ID: <YYFI9GZ9UbEeglMR@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <DM6PR11MB44913064051FD3155BEE2EC89A8B9@DM6PR11MB4491.namprd11.prod.outlook.com>
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/
next prev parent reply other threads:[~2021-11-02 14:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-29 13:48 Ben Magistro
2021-11-01 15:03 ` Bruce Richardson
2021-11-02 11:20 ` Ananyev, Konstantin
2021-11-02 12:07 ` Bruce Richardson
2021-11-02 12:24 ` Ananyev, Konstantin
2021-11-02 14:19 ` Bruce Richardson [this message]
2021-11-02 15:00 ` Ananyev, Konstantin
2021-11-03 14:38 ` Ben Magistro
2021-11-04 11:03 ` Ananyev, Konstantin
2021-11-04 14:51 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YYFI9GZ9UbEeglMR@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=koncept1@gmail.com \
--cc=konstantin.ananyev@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).