On Mon, Jun 16, 2014 at 04:17:03PM +, Richardson, Bruce wrote:
>
>
> > -Original Message-
> <...snip...>
> > > this doesn't seem like an idea solution either. I'm not 100% clear why
> > > rte_eal_pci_probe is currently called by the application code and not
> > > initiated
> > > fr
On Mon, Jun 16, 2014 at 10:30:54PM +, Richardson, Bruce wrote:
> The below patch is the quickest fix I found to make my applications work
> again, but I'm not sure it's the best solution. Can anyone else offer other
> suggestions to improve this?
>
> > -Original Message-
> > From: Ri
On Tue, Jun 17, 2014 at 04:38:38PM +, Richardson, Bruce wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Richardson, Bruce
> > Sent: Tuesday, June 17, 2014 9:29 AM
> > To: Burakov, Anatoly; dev at dpdk.org
> > Subject: Re: [dpdk-dev] vfio detecti
On Tue, Jun 17, 2014 at 05:45:55PM +, Richardson, Bruce wrote:
>
>
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Tuesday, June 17, 2014 10:42 AM
> > To: Richardson, Bruce
> > Cc: Burakov, Anatoly; dev at
ck for < 0 error codes
Signed-off-by: Neil Horman
CC: Thomas Monjalon
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 4de
On Tue, Jun 17, 2014 at 08:21:29PM +, Richardson, Bruce wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Tuesday, June 17, 2014 12:04 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PA
On Wed, Jun 18, 2014 at 10:26:08AM +, Burakov, Anatoly wrote:
> Hi Cristian,
>
> > I would suggest we add a log message explaining which mechanism is loaded
> > (igb_uio/vfio) and why (e.g. tried vfio first but container could not be
> > opened, so falling back to igb_uio, etc).
>
> This alre
On Wed, Jun 18, 2014 at 11:02:23AM +, Burakov, Anatoly wrote:
> Hi Neil
>
> > I think what Thomas wants is for you to resend the patch with a proper
> > changelog entry added to it, so the commit has an explination of what was
> > changed and, for posterity.
>
> Got it. Can I also incorporate
On Wed, Jun 18, 2014 at 02:07:17PM +0100, Anatoly Burakov wrote:
> This patchset fixes an issue with VFIO where DPDK initialization could
> fail even if the user didn't want to use VFIO in the first place. Also,
> more verbose and descriptive error messages were added to VFIO code, for
> example di
4 app/test/test_link_bonding.c
> create mode 100644 app/test/virtual_pmd.c
> create mode 100644 app/test/virtual_pmd.h
> create mode 100644 lib/librte_pmd_bond/Makefile
> create mode 100644 lib/librte_pmd_bond/rte_eth_bond.c
> create mode 100644 lib/librte_pmd_bond/rte_eth_bond.h
>
>
For the series
Acked-by: Neil Horman
Thanks for all the hard work!
Neil
e_eal/linuxapp/eal/eal_pci_vfio.c | 63
> --
> 1 file changed, 34 insertions(+), 29 deletions(-)
>
> --
> 1.8.1.4
>
>
Series
Acked-by: Neil Horman
Thanks Anatoly!
Neil
On Mon, Jun 23, 2014 at 05:43:21PM -0400, Stefan Baranoff wrote:
> Paul,
>
> Thanks for the advice; we ran memtest as well as the Dell complete system
> diagnostic and neither found an issue. The plot thickens, though!
>
> Our admins messed up our kickstart labels and what I *thought* was CentOS
On Thu, Jun 26, 2014 at 09:22:40PM +0100, Bruce Richardson wrote:
> This is a very simple example app for doing packet forwarding with the
> Intel DPDK. It's designed to serve as a start point for people new to
> the Intel DPDK and who want to develop a new app.
>
> Therefore it's meant to:
> * ha
On Fri, Jun 27, 2014 at 03:46:39PM +0100, Pablo de Lara wrote:
> From: Pablo de Lara
>
> New ring PMD unit test requires extra EAL option (vdev),
> in order to pass, which I believe is incorrect, as this
> test should be focused on testing the API, without needing
> to pass any argument.
>
> Add
On Fri, Jun 27, 2014 at 03:47:07PM +, De Lara Guarch, Pablo wrote:
> Hi Neil,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, June 27, 2014 4:03 PM
> > To: De Lara Guarch, Pablo
> >
Hey there-
I'm interested in doing some work on the DPDK, specifically in creating
a driver backend that interfaces to the kernel using AF_PACKET rather than a
specific card for which a UIO or VFIO driver is available in kernel. I think it
would be nice for the DPDK to have a hardware agno
On Thu, Mar 06, 2014 at 10:26:21PM +0100, Vincent JARDIN wrote:
> librte_pmd_pcap
> http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_pcap
>
Perfect, thanks!
Neil
> On 06/03/2014 22:25, Neil Horman wrote:
> >Hey there-
> > I'm interested in doing some work
nd then a subsequent asm
directive preforming the reverse exchange (again, listing %edi as being
clobbered).
Signed-off-by: Neil Horman
---
lib/librte_eal/common/eal_common_cpuflags.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_comm
nd then a subsequent asm
directive preforming the reverse exchange (again, listing %edi as being
clobbered).
Signed-off-by: Neil Horman
---
Change notes
v2) Fix constraints to ensure that ebx isn't overwritten before asm starts
---
lib/librte_eal/common/eal_common_cpuflags.c | 13 +++
On Wed, Mar 19, 2014 at 08:44:46AM -0700, H. Peter Anvin wrote:
> On 03/19/2014 07:48 AM, Neil Horman wrote:
> > The recent conversion to build dpdk as a DSO has an error in
> > rte_cpu_get_features. When being build with -fpie, %ebx gets clobbered by
> > the
> > cpui
On Wed, Mar 19, 2014 at 09:22:03PM -0700, H. Peter Anvin wrote:
> On 03/19/2014 05:40 PM, Neil Horman wrote:
> > So after some discussion with hpa, I need to self NAK this again, apologies
> > for
> > the noise. Theres some clean up to be done in this area, and I'
On Thu, Mar 20, 2014 at 07:03:23AM -0400, Neil Horman wrote:
> On Wed, Mar 19, 2014 at 09:22:03PM -0700, H. Peter Anvin wrote:
> > On 03/19/2014 05:40 PM, Neil Horman wrote:
> > > So after some discussion with hpa, I need to self NAK this again,
> > > apologies for
&g
s to ebx and edx
are ignored. I chose to go ahead and do that because there is only a single
caller of this function and neither register is ever written currently.
Signed-off-by: Neil Horman
CC: "H. Peter Anvin"
---
lib/librte_eal/common/eal_common_cpuflags.c | 18 +++---
On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
>
> However, the cod
On Thu, Mar 20, 2014 at 09:44:28AM -0700, H. Peter Anvin wrote:
> Neil Horman reported that on x86-64 the upper half of %rbx would get
> clobbered when the code was compiled PIC or PIE, because the
> i386-specific code to preserve %ebx was incorrectly compiled.
>
> However, the cod
On Thu, Mar 20, 2014 at 12:39:21PM -0400, Neil Horman wrote:
> On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC or PIE, because the
> >
On Thu, Mar 20, 2014 at 02:04:43PM -0400, Neil Horman wrote:
> On Thu, Mar 20, 2014 at 12:39:21PM -0400, Neil Horman wrote:
> > On Thu, Mar 20, 2014 at 08:53:50AM -0700, H. Peter Anvin wrote:
> > > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > &
From: "H. Peter Anvin"
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
On Fri, Mar 21, 2014 at 08:03:34AM -0700, H. Peter Anvin wrote:
> On 03/21/2014 07:49 AM, Neil Horman wrote:
> > From: "H. Peter Anvin"
> >
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC
On Thu, Mar 20, 2014 at 10:03:53AM -0700, H. Peter Anvin wrote:
> I just realized there is yet another oddity in this code:
>
> > @@ -78,8 +69,10 @@ struct cpuid_parameters_t {
> > struct feature_entry {
> > enum rte_cpu_flag_t feature;/**< feature name */
>
> The structure conta
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
one thing, the CPUID instruction
On Mon, Mar 24, 2014 at 11:09:52AM -0700, H. Peter Anvin wrote:
> On 03/24/2014 10:44 AM, Neil Horman wrote:
> > * Modified cpuid_reg enum to start at 1 rather than zero
> > * Added CPUID_REG macro to drop enum value by 1 during access
>
> I guess I don't get it... why?
On Mon, Mar 24, 2014 at 01:47:55PM -0700, H. Peter Anvin wrote:
> On 03/24/2014 12:52 PM, Neil Horman wrote:
> >>
> > To add an extra sanity check in rte_get_flag_enabled. If we were moving to
> > the
> > use of C99 initalizers, I wanted something to catch the possi
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
one thing, the CPUID instruction
Neil Horman reported that on x86-64 the upper half of %rbx would get
clobbered when the code was compiled PIC or PIE, because the
i386-specific code to preserve %ebx was incorrectly compiled.
However, the code is really way more complex than it needs to be. For
one thing, the CPUID instruction
remove the test
entirely
Signed-off-by: Neil Horman
---
lib/librte_pmd_pcap/rte_eth_pcap.c | 12
1 file changed, 12 deletions(-)
diff --git a/lib/librte_pmd_pcap/rte_eth_pcap.c
b/lib/librte_pmd_pcap/rte_eth_pcap.c
index fbafd19..fe94a79 100644
--- a/lib/librte_pmd_pcap/rte_eth_pcap.c
On Sat, Mar 29, 2014 at 11:34:46AM +0100, Thomas Monjalon wrote:
> Hi Neil,
>
> 28/03/2014 21:32, Neil Horman :
> > The libpcap library has had the ability to send packets since 2004, theres
> > really no need to test for it. Especially in the way dpdk is doing as, as
On Thu, May 01, 2014 at 08:53:02AM +0200, Thomas Monjalon wrote:
> 2014-04-30 11:22, Neil Horman:
> > On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > > The 4 spec files are used to build 4 different git trees with their own
> > > versioning:
>
g/depmod in scriplets
>
> Thanks for your comments/reviews.
> --
> Thomas
>
I understand that this is holding up the 1.6.0r2 release, as well as the 1.7.0
integration. As such, given that my concerns, while valid IMO, aren't required
for the release:
Acked-by: Neil Horman
But -L is also a gcc option. And allowing gcc to process this option fixes
> the issue.
>
> Signed-off-by: Thomas Monjalon
Acked-by: Neil Horman
On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote:
> 2014-04-16 09:51, Neil Horman:
> > The shared libraries built with the current makefile set produce static
> > libraries rather than actual shared objects. This is due to several missing
> > options that are
On Fri, May 02, 2014 at 02:22:17PM +0200, Thomas Monjalon wrote:
> 2014-05-02 07:09, Neil Horman:
> > On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote:
> > > 2014-04-16 09:51, Neil Horman:
> > > > The shared libraries built with the curre
On Fri, May 02, 2014 at 04:42:56PM -0700, Stephen Hemminger wrote:
> The DPDK dump functions are useful for remote debugging of an
> applications. But when application runs as a daemon, stdout
> is typically routed to /dev/null.
>
> Instead change all these functions to take a stdio FILE * handle
On Sun, May 04, 2014 at 01:17:50PM -0700, Stephen Hemminger wrote:
> On Sun, 4 May 2014 08:20:54 -0400
> Neil Horman wrote:
>
> > On Fri, May 02, 2014 at 04:42:56PM -0700, Stephen Hemminger wrote:
> > > The DPDK dump functions are useful for remote debugging of an
>
On Mon, May 05, 2014 at 06:55:31PM -0700, Stephen Hemminger wrote:
> On Mon, 5 May 2014 06:53:09 -0400
> Neil Horman wrote:
>
> > On Sun, May 04, 2014 at 01:17:50PM -0700, Stephen Hemminger wrote:
> > > On Sun, 4 May 2014 08:20:54 -0400
> > > Neil Horman wro
On Mon, May 12, 2014 at 11:11:56AM +0200, Thomas Monjalon wrote:
> Hi,
>
> Your email is invalid because of a "proprietary disclaimer".
>
> Please stop sending such emails.
>
>
Except that this totally happens if you set RHEL_RELEASE_CODE to somthing larger
than (6,4). ethtool_adv_to_mmd_eee_a
On Mon, May 12, 2014 at 02:36:12PM +, Venkatesan, Venky wrote:
> Olivier,
>
> This is a hugely problematic change, and has a pretty large performance
> impact (because the dependency to compute and access). We debated this for a
> long time during the early days of DPDK and decided against
If you
think thats a problem, then we really need to get details of your test case and
measurements you took so that they can be reproduced, and confirmed or refuted.
Regards
Neil.
> Regards,
> -Venky
>
>
>
>
> -Original Message-
> From: Olivier MATZ [mailto:oli
Hey all-
This isn't really germaine to dpdk development, but Thomas and Vincent,
you expressed interest in my progress regarding packaging of dpdk for Fedora, so
I figured I would post here in case others were interested.
Please find here:
http://people.redhat.com/nhorman/dpdk-1.7.0-0.1.gi
On Wed, May 14, 2014 at 12:46:38AM +0200, Vincent JARDIN wrote:
> Neil,
>
> > Please find here:
> > http://people.redhat.com/nhorman/dpdk-1.7.0-0.1.gitb20539d68.src.rpm
>
> Your spec file is broken:
>
> A simple patch:
> --- dpdk.spec 2014-05-13 22:43:15.89200 +
> +++ ../dpdk.spec.vj
On Mon, Apr 21, 2014 at 10:59:25AM -0400, Neil Horman wrote:
> Disconnect compile time linkage between eal library / applications and pmd's
>
> I noticed that, while tinkering with dpdk, building for shared libraries still
> resulted in all the test applications linking to al
On Fri, May 16, 2014 at 07:15:11PM +0100, Bruce Richardson wrote:
> This patch set aims to provide a shorter simpler alternative the public API
> functions for using rings as ethdevs provided by the librte_pmd_ring library.
> This alternative just provides simple RX and TX burst functions and a
ualization PMDs
> (virtio/vmxnet3) are missing.
>
They're in separate repositories, I was planning on packaging them at a later
time separately, since their versioning and development is handled separately.
> 2014-05-13 15:08, Neil Horman:
> > My current effort to do so. I&#x
On Mon, May 19, 2014 at 10:59:18AM +, Richardson, Bruce wrote:
>
>
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, May 16, 2014 7:54 PM
> > To: Richardson, Bruce
> > Cc: dev at dpdk.org
> >
On Mon, May 19, 2014 at 06:28:47PM +0200, Thomas Monjalon wrote:
> 2014-05-19 09:18, Neil Horman:
> > On Mon, May 19, 2014 at 12:11:35PM +0200, Thomas Monjalon wrote:
> > > My main concerns are about naming and extensions.
> > > We must keep "dpdk-core" namin
On Tue, May 20, 2014 at 11:00:53AM +0100, Bruce Richardson wrote:
> This adds a new library to the Intel DPDK whereby a set of packets can be
> distributed one-at-a-time to a set of worker cores, with dynamic load
> balancing being done between those workers. Flows are identified by a tag
> with
On Tue, May 20, 2014 at 02:45:09PM +0200, Thomas Monjalon wrote:
> 2014-04-21 10:59, Neil Horman:
> > Disconnect compile time linkage between eal library / applications and pmd's
> >
> > I noticed that, while tinkering with dpdk, building for shared libraries
> >
On Tue, May 20, 2014 at 11:02:15AM +, Richardson, Bruce wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Tuesday, May 20, 2014 11:39 AM
> > To: Richardson, Bruce
> > Cc: dev at dpdk.org
> > Subject: Re
On Tue, May 20, 2014 at 11:00:55AM +0100, Bruce Richardson wrote:
> This adds the code for a new Intel DPDK library for packet distribution.
> The distributor is a component which is designed to pass packets
> one-at-a-time to workers, with dynamic load balancing. Using the RSS
> field in the mbuf
On Wed, May 21, 2014 at 10:21:26AM +, Richardson, Bruce wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Tuesday, May 20, 2014 7:19 PM
> > To: Richardson, Bruce
> > Cc: dev at dpdk.org
> > Subject: Re
On Sun, May 25, 2014 at 09:39:22PM +, Gilmore, Walter E wrote:
> Olivier you're making an assumption that customer application code running on
> the Intel DPDK isn't using the rte_ctrlmbuf structure.
> Remember there are more than 300 customers using the Intel DPDK and there is
> no way you
On Mon, May 26, 2014 at 03:45:28PM +0800, Ouyang Changchun wrote:
> This patch v2 fixes some errors and warnings reported by checkpatch.pl.
>
> This patch series also contain the 3 items:
> 1. Add API to support setting TX rate for a queue or a VF.
> 2. Implement the functionality of setting TX r
On Tue, May 27, 2014 at 06:09:23PM +0100, Cristian Dumitrescu wrote:
> Intel DPDK Packet Framework provides a standard methodology (logically
> similar to OpenFlow) for rapid development of complex packet processing
> pipelines out of ports, tables and actions.
>
> A pipeline is constructed by c
On Tue, May 27, 2014 at 02:55:16PM +0200, Thomas Monjalon wrote:
> Some linker options were not prefixed by -Wl, when using gcc:
> -z muldefs
> -melf_i386 (32-bit config)
>
> Using macro linkerprefix is fixing it.
>
> Signed-off-by: Thomas Monjalon
> ---
> mk/rte.lib.mk | 6 --
>
On Wed, May 28, 2014 at 04:32:00PM +0100, declan.doherty at intel.com wrote:
> From: Declan Doherty
>
> Initial release of Link Bonding Library (lib/librte_bond) with support for
> bonding modes :
> 0 - Round Robin
> 1 - Active Backup
> 2 - Balance l2 / l23 / l34
> 3 - Broadcast
>
Why make
On Thu, May 29, 2014 at 08:24:56AM +0200, Thomas Monjalon wrote:
> Hi Neil,
>
> 2014-05-28 10:17, Neil Horman:
> > On Tue, May 27, 2014 at 02:55:16PM +0200, Thomas Monjalon wrote:
> > > Some linker options were not prefixed by -Wl, when using gcc:
> > > -z m
On Thu, May 29, 2014 at 10:33:00AM +, Doherty, Declan wrote:
> -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Wednesday, May 28, 2014 6:49 PM
> > To: Doherty, Declan
> > Cc: dev at dpdk.org
> > Subject: Re: [d
> +
> +/* flush the distributor, so that there are no outstanding packets in flight
> or
> + * queued up. */
Its not clear to me that this is a distributor only function. You modified the
comments to indicate that lcores can't preform double duty as both a worker and
a distributor, which is fine,
On Fri, Oct 31, 2014 at 05:36:59PM +, O'driscoll, Tim wrote:
> Thanks again to those who attended the call earlier. Hopefully people found
> it useful.
>
> We'll schedule a follow-up call for 2 weeks' time. One thing that we do want
> to look into is an easy way to allow screen sharing, so t
On Mon, Nov 03, 2014 at 02:25:51PM +, Wiles, Roger Keith wrote:
>
> > On Nov 3, 2014, at 8:16 AM, Bruce Richardson > intel.com> wrote:
> >
> > On Mon, Nov 03, 2014 at 02:08:46PM +, Wiles, Roger Keith wrote:
> >>
> >>> On Nov 3, 2014, at 4:41 AM, Bruce Richardson >>> intel.com> wrote:
>
On Mon, Nov 03, 2014 at 03:26:50PM -0800, Stephen Hemminger wrote:
> On Mon, 3 Nov 2014 16:50:15 +
> "Wiles, Roger Keith" wrote:
>
> >
> > > On Nov 3, 2014, at 10:06 AM, Neil Horman wrote:
> > >
> > > On Mon, Nov 03, 2014 at 02:25:51PM
On Tue, Nov 04, 2014 at 04:52:48AM +, Wiles, Roger Keith wrote:
>
> > On Nov 3, 2014, at 5:42 PM, Neil Horman wrote:
> >
> > On Mon, Nov 03, 2014 at 03:26:50PM -0800, Stephen Hemminger wrote:
> >> On Mon, 3 Nov 2014 16:50:15 +
> >> "Wiles, Rog
On Tue, Nov 04, 2014 at 02:44:39PM +, Wiles, Roger Keith wrote:
>
> > On Nov 4, 2014, at 5:27 AM, Neil Horman wrote:
> >
> > On Tue, Nov 04, 2014 at 04:52:48AM +, Wiles, Roger Keith wrote:
> >>
> >>> On Nov 3, 2014, at 5:42 PM, Neil Horman w
On Tue, Nov 04, 2014 at 08:45:53PM +, Wiles, Roger Keith wrote:
>
> >>
> > Can you provide a real example here? usnig vague terms like "huge" really
> > makes
> > more of an emotional argument than a factual one. To cite an example the
> > cmdline_test program adds a command line paramter
virtio-net.c| 317
> +--
> 6 files changed, 494 insertions(+), 397 deletions(-)
>
Acked-by: Neil Horman
ng arg)
> put_files_struct(files);
>
> if (file == NULL) {
> - printk(KERN_DEBUG "Failed to get file from target
> pid\n");
> + pr_debug("Failed to get file from target pid\n");
> return 0;
> }
>
> --
> 1.8.1.4
>
>
Acked-by: Neil Horman
On Sat, Nov 08, 2014 at 01:35:42AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> lib/librte_pmd_enic/LICENSE | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 lib/librte_pmd_enic/LICENSE
>
> diff --git a/lib/librte_pmd_enic/LICENSE b/lib/
On Sat, Nov 08, 2014 at 01:35:41AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> app/test-pmd/testpmd.c | 1 +
> config/common_linuxapp | 6 ++
> lib/Makefile | 1 +
> lib/librte
On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> lib/librte_pmd_enic/Makefile | 66
>
> 1 file changed, 66 insertions(+)
> create mode 100644 lib/librte_pmd_enic/Makefile
>
> diff --git a/lib/libr
On Fri, Nov 07, 2014 at 01:13:37PM +, Nicolas Pernas Maradei wrote:
> On 07/11/14 12:55, Thomas Monjalon wrote:
> >It's by design. If you add a vdev, you want to use it and there is no
> >reason to whitelist it, and especially no reason to blacklist a device
> >you created for your usage.
> >
>
On Fri, Nov 07, 2014 at 01:39:52PM +, Nicolas Pernas Maradei wrote:
>
> On 07/11/14 13:26, Neil Horman wrote:
> >Then you create the pcap device with --vdev, and simply don't load the pmds
> >for
> >any of your physical devices (or just don't use pci-whiteli
back with V2.
> >
> >Regards,
> >-Sujith
> >
> >On 07/11/14 5:04 pm, "Neil Horman" wrote:
> >
> >>On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote:
> >>> Signed-off-by: Sujith Sankar
> >>> ---
> >>&
On Tue, Nov 11, 2014 at 03:26:04PM +, De Lara Guarch, Pablo wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky
> > Sent: Tuesday, November 11, 2014 3:17 PM
> > To: Gonzalez Monroy, Sergio
> > Cc: dev at dpdk.org
> > Subject: R
On Wed, Apr 02, 2014 at 10:13:30AM +0200, Thomas Monjalon wrote:
> Hello,
>
> 2014-04-01 23:35, Fred Pedrisa:
> > I've created an unofficial channel in freenode irc network, so for those
> > interested in joining there for a better chatting here are the informations
> >
> > Server : irc.freenode.
On Tue, Mar 25, 2014 at 01:51:04PM -0700, H. Peter Anvin wrote:
> On 03/25/2014 12:52 PM, Neil Horman wrote:
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC or PIE, because the
> > i386-specific code
On Wed, Apr 02, 2014 at 11:53:51AM +0200, Thomas Monjalon wrote:
> Hello,
>
> Sorry for the long delay.
>
> 2014-02-26 14:07, Thomas Graf:
> > On 02/04/2014 04:54 PM, Thomas Monjalon wrote:
> > > +Version: 1.5.2r1
> > > +Release: 1
> >
> > What kind of upgrade strategy do you have in mind?
> >
Hey all-
I was going to include this as an addendum to the packaging thread on
this list, but I can't seem to find it in my inbox, so forgive me starting a new
one.
I wanted to broach the subject of ABI/API stability on the list here.
Given the recent great efforts to make dpdk pac
On Wed, Apr 09, 2014 at 02:08:49PM -0700, Stephen Hemminger wrote:
> On Wed, 9 Apr 2014 14:39:52 -0400
> Neil Horman wrote:
>
> > Hey all-
> > I was going to include this as an addendum to the packaging thread on
> > this list, but I can't seem to find it in
Disconnect compile time linkage between eal library / applications and pmd's
I noticed that, while tinkering with dpdk, building for shared libraries still
resulted in all the test applications linking to all the built pmd's, despite
not actually needing them all. We are able to tell an applicati
to the use of
CC rather than LD and fixing the -shared option corrects these problems and
builds the DSOs correctly.
Signed-off-by: Neil Horman
---
mk/rte.lib.mk | 4 ++--
mk/rte.sharelib.mk | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
Signed-off-by: Neil Horman
---
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_nonpci_devs.c | 60 +-
lib/librte_eal/common/include/rte_pmd.h| 59 +
3 files changed, 119 insertions(+), 2 deletions(-)
c
We need to call dlopen on any DSO's referenced on the command line before
calling their init routines. This provides the DSO's the opportunity to run the
constructors created by the PMD_INIT_NONPCI macro prior to the init list being
traversed.
Signed-off-by: Neil Horman
---
lib/
Convert the pcap poll mode driver to link itself to libpcap and register a init
routine via the PMD_INIT_NONPCI macro
Signed-off-by: Neil Horman
---
lib/librte_eal/common/eal_common_nonpci_devs.c | 9 -
lib/librte_pmd_pcap/Makefile | 2 ++
lib/librte_pmd_pcap
the proper pmd. for now I've just added linkage to the pmd directly to
avoid build breaks and will fix up the application operation in a subsequent
patch
Signed-off-by: Neil Horman
---
app/test/Makefile | 2 ++
lib/librte_eal/common/eal_common_nonpci_devs.c
Convert the xenvirt driver to use the PMD_INIT_NONPCI macro so that we can break
the linkages between it and the core library to avoid unnneded loading when
built as a DSO
Signed-off-by: Neil Horman
---
lib/librte_eal/common/eal_common_nonpci_devs.c | 9 -
lib/librte_pmd_xenvirt
Now that we've converted the available PMD drivers to use the PMD_INIT_NONPCI
macro, we can remove the rest of the old init code
Signed-off-by: Neil Horman
---
lib/librte_eal/common/eal_common_nonpci_devs.c | 34 +-
1 file changed, 1 insertion(+), 33 deletions(-)
the test application calls functions in the pmd_pcap driver directly. We
should fix this properly, but for now just link in the library
Signed-off-by: Neil Horman
---
mk/rte.app.mk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index
when doing a static link, we need to add -lpacp to testpmd because it will need
to resolve those symbols when it links in librte_pmd_pcap.a
Signed-off-by: Neil Horman
---
mk/rte.app.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index
-by: Neil Horman
---
mk/rte.app.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 2f2ff16..41eab08 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -198,6 +198,8 @@ endif
ifeq ($(LINK_USING_CC),1)
comma := ,
LDLIBS := $(addprefix -Wl$(comma),$(LDLIBS
Organizational change in support of doing dynamic init routine registration
Signed-off-by: Neil Horman
---
lib/librte_ether/rte_ethdev.c | 52 ++
lib/librte_ether/rte_ethdev.h | 53 +--
2 files changed, 53
1 - 100 of 1694 matches
Mail list logo
