Message ID | 20150101040032.GA11645@hmsreliant.think-freely.org (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id D51D55A44; Thu, 1 Jan 2015 05:00:40 +0100 (CET) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 3154B5A3F for <dev@dpdk.org>; Thu, 1 Jan 2015 05:00:39 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from <nhorman@tuxdriver.com>) id 1Y6Ww7-0004vF-KX; Wed, 31 Dec 2014 23:00:37 -0500 Date: Wed, 31 Dec 2014 23:00:32 -0500 From: Neil Horman <nhorman@tuxdriver.com> To: Lyn M <netinal7@gmail.com> Message-ID: <20150101040032.GA11645@hmsreliant.think-freely.org> References: <CAM8Q2aVXRMbJZ3u25u_P1hwy_acGGvBQEQr8-CLmWwNK-HPfNg@mail.gmail.com> <20141229210210.GA31480@localhost.localdomain> <CAM8Q2aXo5RhtrYnV+SSB_gDkG5OeZ-BCDqib+xaGG84rmRK2iQ@mail.gmail.com> <20141230212406.GB2187@localhost.localdomain> <CAM8Q2aUYDQ-+wkLn9hPTNKQnLwBqJOcA2tTO=WFt3eY-sUXnyQ@mail.gmail.com> <20141231144859.GA6637@localhost.localdomain> <CAM8Q2aXiXv+WBQPg5PLn7aGp_2V=a=Rcm1vPrXC2u5EycLaZfw@mail.gmail.com> <20150101033744.GA8149@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150101033744.GA8149@localhost.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] l3fwd error, port 0 is not present on the board X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Neil Horman
Jan. 1, 2015, 4 a.m. UTC
On Wed, Dec 31, 2014 at 10:37:45PM -0500, Neil Horman wrote: > On Wed, Dec 31, 2014 at 10:50:10AM -0600, Lyn M wrote: > > Neil, > > When I build DPDK 1.8.0 with the default value CONFIG_RTE_BUILD_COMBINE_LIBS=n, > > I am able to run the testpmd successfully. So, that does appear to be the > > culprit. > > The objdump -t output for testpmd (with COMBINE_LIBS=n and COMBINE_LIBS=y) > > files are here: > > https://www.dropbox.com/sh/6os9yfn22jjcnmy/AAAjEV3u06XQ1t3UXdWcgru0a?dl=0 > > > > Thanks, > > Lyn > > > I see the problem. none of the constructors are included in the l3fwd app. I > think you might need 174572477028b7f04700389e38f87d2ba01a0adc. Its also > possible something else has gone wrong withthe COMBINE_LIBS option. Try > building with the head of the tree, and if that doesn't fix it, we can start > debugging in earnest. > Neil Found the problem. Please try this patch
Comments
Neil, your patch works. I am now able to run testpmd, as well as l3fwd with DPDK 1.8.0 and CONFIG_RTE_BUILD_COMBINE_LIBS=y. Thank you much! In my original post, I thought my choice of hex portmask -p 0x3 was causing this issue -- now I know that was not the case. But, I am still curious about how the hex portmask is determined. Since I only have two ports bound to igb_uio, my hex postmask will always be 0x3? What if I choose to bind other ports to igb_uio? Is there a Linux command I can run to determine what mask to use with the -p option? Happy New Year -- Lyn On Wed, Dec 31, 2014 at 10:00 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > On Wed, Dec 31, 2014 at 10:37:45PM -0500, Neil Horman wrote: > > On Wed, Dec 31, 2014 at 10:50:10AM -0600, Lyn M wrote: > > > Neil, > > > When I build DPDK 1.8.0 with the default value > CONFIG_RTE_BUILD_COMBINE_LIBS=n, > > > I am able to run the testpmd successfully. So, that does appear to be > the > > > culprit. > > > The objdump -t output for testpmd (with COMBINE_LIBS=n and > COMBINE_LIBS=y) > > > files are here: > > > > https://www.dropbox.com/sh/6os9yfn22jjcnmy/AAAjEV3u06XQ1t3UXdWcgru0a?dl=0 > > > > > > Thanks, > > > Lyn > > > > > I see the problem. none of the constructors are included in the l3fwd > app. I > > think you might need 174572477028b7f04700389e38f87d2ba01a0adc. Its also > > possible something else has gone wrong withthe COMBINE_LIBS option. Try > > building with the head of the tree, and if that doesn't fix it, we can > start > > debugging in earnest. > > Neil > > Found the problem. Please try this patch > > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk > index e1a0dbf..40afb2c 100644 > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -61,6 +61,10 @@ ifeq ($(NO_AUTOLIBS),) > > LDLIBS += --whole-archive > > +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) > +LDLIBS += -l$(RTE_LIBNAME) > +endif > + > ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) > > ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) > @@ -251,10 +255,6 @@ build: _postbuild > > exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1)))) > > -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) > -LDLIBS += -l$(RTE_LIBNAME) > -endif > - > ifeq ($(LINK_USING_CC),1) > override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS)) > O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \ >
On Fri, Jan 02, 2015 at 09:07:40AM -0600, Lyn M wrote: > Neil, your patch works. I am now able to run testpmd, as well as l3fwd > with DPDK 1.8.0 and CONFIG_RTE_BUILD_COMBINE_LIBS=y. Thank you much! > I'll post it for official review shortly. > In my original post, I thought my choice of hex portmask -p 0x3 was causing > this issue -- now I know that was not the case. But, I am still curious > about how the hex portmask is determined. Since I only have two ports > bound to igb_uio, my hex postmask will always be 0x3? What if I choose to > bind other ports to igb_uio? Is there a Linux command I can run to > determine what mask to use with the -p option? > portmask IIRC is determined by the cpus you decide you want to service various hardware queues. you can select whatever cpus you want, so in a sense, the portmask is entirely your decision. If you want it to be optimal, you should select a portmask where the cpus servicing your hardware are on the same numa node as the NIC itself. You should be able to determine the cpu numa node locality via /sys/class/net/<iface>/device/local_cpus Neil > Happy New Year -- > Lyn > > On Wed, Dec 31, 2014 at 10:00 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > > > On Wed, Dec 31, 2014 at 10:37:45PM -0500, Neil Horman wrote: > > > On Wed, Dec 31, 2014 at 10:50:10AM -0600, Lyn M wrote: > > > > Neil, > > > > When I build DPDK 1.8.0 with the default value > > CONFIG_RTE_BUILD_COMBINE_LIBS=n, > > > > I am able to run the testpmd successfully. So, that does appear to be > > the > > > > culprit. > > > > The objdump -t output for testpmd (with COMBINE_LIBS=n and > > COMBINE_LIBS=y) > > > > files are here: > > > > > > https://www.dropbox.com/sh/6os9yfn22jjcnmy/AAAjEV3u06XQ1t3UXdWcgru0a?dl=0 > > > > > > > > Thanks, > > > > Lyn > > > > > > > I see the problem. none of the constructors are included in the l3fwd > > app. I > > > think you might need 174572477028b7f04700389e38f87d2ba01a0adc. Its also > > > possible something else has gone wrong withthe COMBINE_LIBS option. Try > > > building with the head of the tree, and if that doesn't fix it, we can > > start > > > debugging in earnest. > > > Neil > > > > Found the problem. Please try this patch > > > > > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk > > index e1a0dbf..40afb2c 100644 > > --- a/mk/rte.app.mk > > +++ b/mk/rte.app.mk > > @@ -61,6 +61,10 @@ ifeq ($(NO_AUTOLIBS),) > > > > LDLIBS += --whole-archive > > > > +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) > > +LDLIBS += -l$(RTE_LIBNAME) > > +endif > > + > > ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) > > > > ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) > > @@ -251,10 +255,6 @@ build: _postbuild > > > > exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1)))) > > > > -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) > > -LDLIBS += -l$(RTE_LIBNAME) > > -endif > > - > > ifeq ($(LINK_USING_CC),1) > > override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS)) > > O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \ > >
On 1/2/2015 11:08 PM, Lyn M wrote: > Neil, your patch works. I am now able to run testpmd, as well as l3fwd > with DPDK 1.8.0 and CONFIG_RTE_BUILD_COMBINE_LIBS=y. Thank you much! > > In my original post, I thought my choice of hex portmask -p 0x3 was causing > this issue -- now I know that was not the case. But, I am still curious > about how the hex portmask is determined. Since I only have two ports > bound to igb_uio, my hex postmask will always be 0x3? What if I choose to > bind other ports to igb_uio? Is there a Linux command I can run to > determine what mask to use with the -p option? It is simply a mask used to enable or disable ports in DPDK. For example: If DPDK owns two ports, -p 0x03 means all two ports are enabled. If DPDK owns four ports, -p 0x03 means only port 0 and 1 are enabled, port 2 and 3 are unable to use. If you want to enable all ports, you should use -p 0x0f 0x03 is 0b11, 0x0f is 0b1111 Thanks, Michael > Happy New Year -- > Lyn > > On Wed, Dec 31, 2014 at 10:00 PM, Neil Horman <nhorman@tuxdriver.com> wrote: > >> On Wed, Dec 31, 2014 at 10:37:45PM -0500, Neil Horman wrote: >>> On Wed, Dec 31, 2014 at 10:50:10AM -0600, Lyn M wrote: >>>> Neil, >>>> When I build DPDK 1.8.0 with the default value >> CONFIG_RTE_BUILD_COMBINE_LIBS=n, >>>> I am able to run the testpmd successfully. So, that does appear to be >> the >>>> culprit. >>>> The objdump -t output for testpmd (with COMBINE_LIBS=n and >> COMBINE_LIBS=y) >>>> files are here: >>>> >> https://www.dropbox.com/sh/6os9yfn22jjcnmy/AAAjEV3u06XQ1t3UXdWcgru0a?dl=0 >>>> Thanks, >>>> Lyn >>>> >>> I see the problem. none of the constructors are included in the l3fwd >> app. I >>> think you might need 174572477028b7f04700389e38f87d2ba01a0adc. Its also >>> possible something else has gone wrong withthe COMBINE_LIBS option. Try >>> building with the head of the tree, and if that doesn't fix it, we can >> start >>> debugging in earnest. >>> Neil >> Found the problem. Please try this patch >> >> >> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >> index e1a0dbf..40afb2c 100644 >> --- a/mk/rte.app.mk >> +++ b/mk/rte.app.mk >> @@ -61,6 +61,10 @@ ifeq ($(NO_AUTOLIBS),) >> >> LDLIBS += --whole-archive >> >> +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) >> +LDLIBS += -l$(RTE_LIBNAME) >> +endif >> + >> ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) >> >> ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) >> @@ -251,10 +255,6 @@ build: _postbuild >> >> exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1)))) >> >> -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) >> -LDLIBS += -l$(RTE_LIBNAME) >> -endif >> - >> ifeq ($(LINK_USING_CC),1) >> override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS)) >> O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \ >>
2015-01-02 09:07, Lyn M: > In my original post, I thought my choice of hex portmask -p 0x3 was causing > this issue -- now I know that was not the case. But, I am still curious > about how the hex portmask is determined. Since I only have two ports > bound to igb_uio, my hex postmask will always be 0x3? What if I choose to > bind other ports to igb_uio? Is there a Linux command I can run to > determine what mask to use with the -p option? That's something which could be done. Port numbering is defined by probing order. Does a tool showing the (dry-run) probed devices, their number and mask, would help you? By the way, you are welcome to try developing it.
On Tue, Jan 06, 2015 at 10:02:25AM +0100, Thomas Monjalon wrote: > 2015-01-02 09:07, Lyn M: > > In my original post, I thought my choice of hex portmask -p 0x3 was causing > > this issue -- now I know that was not the case. But, I am still curious > > about how the hex portmask is determined. Since I only have two ports > > bound to igb_uio, my hex postmask will always be 0x3? What if I choose to > > bind other ports to igb_uio? Is there a Linux command I can run to > > determine what mask to use with the -p option? > > That's something which could be done. > Port numbering is defined by probing order. Does a tool showing the (dry-run) > probed devices, their number and mask, would help you? > By the way, you are welcome to try developing it. > > -- > Thomas The port numbering should generally be in the same order as the ports are listed in dpdk_nic_bind script, so perhaps we could just add a documentation note to that effect. /Bruce
diff --git a/mk/rte.app.mk b/mk/rte.app.mk index e1a0dbf..40afb2c 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -61,6 +61,10 @@ ifeq ($(NO_AUTOLIBS),) LDLIBS += --whole-archive +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) +LDLIBS += -l$(RTE_LIBNAME) +endif + ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) @@ -251,10 +255,6 @@ build: _postbuild exe2cmd = $(strip $(call dotfile,$(patsubst %,%.cmd,$(1)))) -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) -LDLIBS += -l$(RTE_LIBNAME) -endif - ifeq ($(LINK_USING_CC),1) override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS)) O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \