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
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: :01:03.
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 linking
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
> > >
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 t
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 Muka
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,
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:
> > > > > Just
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. Fo
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 wil
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,
lea
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
--- a/lib/librte_mb
This patch takes the existing TX flags defined for the mbuf and shifts
each uniquely defined one left so that additional RX flags can be
defined without having RX and TX flags mixed together. Under the new
scheme, RX flags start at bit 0 and work left, TX flags start at bit 55
and work right, and b
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(-)
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 concl
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 compatible
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 havin
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
> > multip
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,
.data_o
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 build
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
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.
On Fri, Oct 03, 2014 at 04:52:40PM -0700, Stephen Hemminger wrote:
> 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, inter
23 matches
Mail list logo
