From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id EC546A00E6 for ; Tue, 11 Jun 2019 16:37:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CF41C1C3FF; Tue, 11 Jun 2019 16:37:02 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A1A9B2956 for ; Tue, 11 Jun 2019 16:37:00 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jun 2019 07:36:59 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by fmsmga005.fm.intel.com with SMTP; 11 Jun 2019 07:36:56 -0700 Received: by (sSMTP sendmail emulation); Tue, 11 Jun 2019 15:36:55 +0100 Date: Tue, 11 Jun 2019 15:36:55 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: David Marchand , Ilya Maximets , dev , Ian Stokes , Aaron Conole , "ovs-dev@openvswitch.org" , "Yigit, Ferruh" Message-ID: <20190611143655.GA471@bricha3-MOBL.ger.corp.intel.com> References: <20190611101822.GB457@bricha3-MOBL.ger.corp.intel.com> <20190611072509.736ba3be@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190611072509.736ba3be@hermes.lan> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] Forcing inlining for igb_uio and kni X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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, Jun 11, 2019 at 07:25:09AM -0700, Stephen Hemminger wrote: > On Tue, 11 Jun 2019 11:18:22 +0100 > Bruce Richardson 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....