DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
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 15:36:55 +0100	[thread overview]
Message-ID: <20190611143655.GA471@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20190611072509.736ba3be@hermes.lan>

On Tue, Jun 11, 2019 at 07:25:09AM -0700, Stephen Hemminger wrote:
> 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.

I agree, especially for uio module. This was not a "perf" issue, but a
"just own't compile" issue, IIRC. :-)

That being said, given that this is just a line in two makefiles, the rule
about "if it ain't broke" may apply....

      reply	other threads:[~2019-06-11 14:37 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
2019-06-11 14:36           ` Bruce Richardson [this message]

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=20190611143655.GA471@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=aconole@redhat.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 \
    --cc=stephen@networkplumber.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).