DPDK patches and discussions
 help / color / mirror / Atom feed
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 12:07:43 +0000	[thread overview]
Message-ID: <YYEqDpTAbPXR6HbB@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <DM6PR11MB4491BAD545EB283506F3A1A39A8B9@DM6PR11MB4491.namprd11.prod.outlook.com>

On Tue, Nov 02, 2021 at 11:20:04AM +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.

> 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.

/Bruce 

  reply	other threads:[~2021-11-02 12:08 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 [this message]
2021-11-02 12:24       ` Ananyev, Konstantin
2021-11-02 14:19         ` Bruce Richardson
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=YYEqDpTAbPXR6HbB@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).