DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: David Marchand <david.marchand@redhat.com>,
	Ilya Maximets <i.maximets@samsung.com>, dev <dev@dpdk.org>,
	Ian Stokes <ian.stokes@intel.com>,
	Aaron Conole <aconole@redhat.com>,
	"ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] Forcing inlining for igb_uio and kni
Date: Tue, 11 Jun 2019 07:25:09 -0700	[thread overview]
Message-ID: <20190611072509.736ba3be@hermes.lan> (raw)
In-Reply-To: <20190611101822.GB457@bricha3-MOBL.ger.corp.intel.com>

On Tue, 11 Jun 2019 11:18:22 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Tue, Jun 11, 2019 at 11:44:01AM +0200, David Marchand wrote:
> >    On Tue, Jun 11, 2019 at 11:31 AM Ilya Maximets
> >    <[1]i.maximets@samsung.com> wrote:
> > 
> >      On 11.06.2019 11:45, David Marchand wrote:  
> >      > I noticed that OVS CI [1] patches the dpdk sources to force some  
> >      inlining parameters and get kni and igb_uio to build fine.  
> >      >
> >      > Looking at it in dpdk, meson support dropped this.
> >      > In the makefiles, I can't find a reason in the git history (we go  
> >      back to 1.3.0rX version).  
> >      >
> >      > [dmarchan@dmarchan dpdk]$ git grep max-inline-insns-single
> >      > kernel/linux/igb_uio/Makefile:MODULE_CFLAGS += -I$(SRCDIR) --param  
> >      max-inline-insns-single=100  
> >      > kernel/linux/kni/Makefile:MODULE_CFLAGS += -I$(SRCDIR) --param  
> >      max-inline-insns-single=50  
> >      > [dmarchan@dmarchan dpdk]$ git blame origin/master --  
> >      kernel/linux/igb_uio/Makefile |grep max-inline-insns-single  
> >      > 13dc56a6 lib/librte_eal/linuxapp/igb_uio/Makefile (Intel  
> >       2012-12-20 00:00:00 +0100 15) MODULE_CFLAGS += -I$(SRCDIR) --param
> >      max-inline-insns-single=100  
> >      > [dmarchan@dmarchan dpdk]$ git blame origin/master --  
> >      kernel/linux/kni/Makefile |grep max-inline-insns-single  
> >      > 3fc5ca2f lib/librte_eal/linuxapp/kni/Makefile (Intel  
> >      2012-12-20 00:00:00 +0100 14) MODULE_CFLAGS += -I$(SRCDIR) --param
> >      max-inline-insns-single=50  
> >      >
> >      > Is there a valid reason to keep this?
> >      > 1:  
> >      [2]https://github.com/openvswitch/ovs/blob/master/.travis/linux-buil
> >      d.sh#L81
> >      <[3]https://protect2.fireeye.com/url?k=b7de159c45b1fa79.b7df9ed3-c48
> >      06461f28ecaf5&u=https://github.com/openvswitch/ovs/blob/master/.trav
> >      is/linux-build.sh#L81>
> >      Hi, David.
> >      I don't know the reason for these in OVS travis config, But we don't
> >      need to know them, actually. I have a patch to drop all the kernel
> >      related stuff from the DPDK build in OVS Travis checks, just didn't
> >      send it yet. Will send soon, probably.
> > 
> >    I had this in mind since we don't need those kmods in the CI.
> >    Thanks Ilya.
> >    The question on dpdk side remains open :-).
> >    --
> >    David Marchand  
> 
> I know that previously we did have issues with the modules not compiling
> due to errors about maximum levels of inlines. Whether that was because of
> the compiler, or the kernel makefiles at the time, I'm not sure. The kmods
> seem to build fine for me now without the parameters, and the fact that
> there has never been a problem reported with building using meson either,
> probably indicates that the extra compiler flags can be dropped.
> 
> /Bruce

I really doubt forcing inlining makes any difference to the performance.

  reply	other threads:[~2019-06-11 14:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190611084549epcas5p42a1a9b787cf71df23f18ebaf4092beaa@epcas5p4.samsung.com>
2019-06-11  8:45 ` David Marchand
2019-06-11  9:31   ` Ilya Maximets
2019-06-11  9:44     ` David Marchand
2019-06-11 10:18       ` Bruce Richardson
2019-06-11 14:25         ` Stephen Hemminger [this message]
2019-06-11 14:36           ` Bruce Richardson

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=20190611072509.736ba3be@hermes.lan \
    --to=stephen@networkplumber.org \
    --cc=aconole@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=i.maximets@samsung.com \
    --cc=ian.stokes@intel.com \
    --cc=ovs-dev@openvswitch.org \
    /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).