Cleanup the code some to remove n_orig variable that was not required.
Update the comments to __mempool_get_bulk to state the correct return value.
Signed-off-by: Keith Wiles
I run into a problem with Clang report problem when I tried to add another
member to the static initializer of the following in file ixgbe_rxtx_vec.c
int
ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
{
static struct rte_mbuf mb_def = {
.nb_segs = 1,
On Fri, 3 Oct 2014 07:28:33 -0400
Neil Horman wrote:
> I.e. you can ship your pmd's
> pacakged separately from your core
I was hoping only the application API would be "stable"
As we know from Linux kernel, internal API's will never remain stable.
Add in a doxygen comment for the ctrl mbuf flag definition.
Signed-off-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index a4487bb..8581e15 100644
---
Update the format of the RX flags to match that of the TX flags. In
general the flags are now specified as "1ULL << X", with a few
exceptions.
Signed-off-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
This patchset does some cleanup work on the mbuf flag definitions. It is
based off the ideas discussed in the previous RFC patch.
[Ref: http://thread.gmane.org/gmane.comp.networking.dpdk.devel/6155]
Summary of changes:
* Adjust TX flags to start at bit 55 in flags field and work downwards,
Hello Chao,
On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu wrote:
> The set of patches split x86 architecture specific operations from DPDK
> and put them to the
> arch directories of i686 and x86_64 architecture. This will make the
> adpotion of DPDK much easier
> on other computer architecture.
On Fri, Oct 03, 2014 at 11:17:13AM -0700, Matthew Hall wrote:
> On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote:
> > This makes good sense to me. A single archive is just easier in the static
> >
> > case, since the resulting binary will strip out unused code anyway, and
> >
On Fri, Oct 03, 2014 at 03:21:53PM +0200, David Marchand wrote:
> Hello Chao,
>
> On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu wrote:
>
> > The set of patches split x86 architecture specific operations from DPDK
> > and put them to the
> > arch directories of i686 and x86_64 architecture. This
On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote:
> With a single archive, you get everything you build even if you don't need
> it.
Right, I was trying to avoid that for people who specifically didn't want it,
if there are any... I'm not one of them.
> But presumably if you're
On Thu, Oct 02, 2014 at 06:05:09PM +0900, Tetsuya Mukawa wrote:
> (2014/10/02 17:53), Sergio Gonzalez Monroy wrote:
> > On Thu, Oct 02, 2014 at 05:28:04PM +0900, Tetsuya Mukawa wrote:
> >> (2014/10/02 17:12), Sergio Gonzalez Monroy wrote:
> >>> On Thu, Oct 02, 2014 at 11:48:37AM +0900, Tetsuya
On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > Just out of curiosity, whats the impetus behind a single shared library
> > > here?
> > > Is it just
On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote:
> This makes good sense to me. A single archive is just easier in the static
> case, since the resulting binary will strip out unused code anyway, and
> multiple
> libraries are needed in the shared case so that we don't wind up
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote:
> The proposal is to always build single (combined) lib AND to build separated
> libs in case of shared libraries.
> For static library: only one single (combined) static library.
In the static case, this won't be backward
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> We need to simplify build options. So I'm fine to remove COMBINE_LIBS option
> to always enable it.
> About making only one single static library, I think it's a good idea if
> it brings a real code simplification.
>
> So the
2014-10-03 09:10, Sergio Gonzalez Monroy:
> On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> > 2014-10-02 13:04, Matthew Hall:
> > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > > Just out of curiosity, whats the impetus behind a single shared library
> > >
2014-10-02 13:04, Matthew Hall:
> On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > Just out of curiosity, whats the impetus behind a single shared library
> > here?
> > Is it just to ease application linking operations? If so, it almost seems
> > to me
> > that we should abandon
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> 2014-10-02 13:04, Matthew Hall:
> > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > Just out of curiosity, whats the impetus behind a single shared library
> > > here?
> > > Is it just to ease application
Hi,
I am trying to run multiple dpdk forwarding applications on VMs (KVM). The
settings are as followings
Dpdk version: master
PF1 (port 2 of an Intel I350-T4 NIC) has two VFs: VF1(pci: :01:01.0), VF2
(pci: :01:02.0)
PF2 (port 3 of an Intel I350-T4NIC ) has two VFs: VF3 (pci:
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote:
> 2014-10-03 09:10, Sergio Gonzalez Monroy:
> > On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> > > 2014-10-02 13:04, Matthew Hall:
> > > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > > >
On Fri, Oct 03, 2014 at 11:31:10AM +0100, Sergio Gonzalez Monroy wrote:
> On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> > On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > > Just out of curiosity,
21 matches
Mail list logo
