From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"Hunt, David" <david.hunt@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"viktorin@rehivetech.com" <viktorin@rehivetech.com>
Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool operations
Date: Thu, 9 Jun 2016 11:49:44 +0000 [thread overview]
Message-ID: <VI1PR0401MB2061860D8DA2619EE63A367D905F0@VI1PR0401MB2061.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20160609103126.GA27529@localhost.localdomain>
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Thursday, June 09, 2016 4:02 PM
> To: Hunt, David <david.hunt@intel.com>
> Cc: Shreyansh Jain <shreyansh.jain@nxp.com>; dev@dpdk.org;
> olivier.matz@6wind.com; viktorin@rehivetech.com
> Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool
> operations
>
> On Thu, Jun 09, 2016 at 10:39:46AM +0100, Hunt, David wrote:
> > Hi Shreyansh,
> >
> > On 8/6/2016 2:48 PM, Shreyansh Jain wrote:
> > > Hi David,
> > >
> > > Thanks for explanation. I have some comments inline...
> > >
> > > > -----Original Message-----
> > > > From: Hunt, David [mailto:david.hunt@intel.com]
> > > > Sent: Tuesday, June 07, 2016 2:56 PM
> > > > To: Shreyansh Jain <shreyansh.jain@nxp.com>; dev@dpdk.org
> > > > Cc: olivier.matz@6wind.com; viktorin@rehivetech.com;
> > > > jerin.jacob@caviumnetworks.com
> > > > Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external
> mempool
> > > > operations
> > > >
> > > > Hi Shreyansh,
> > > >
> > > > On 6/6/2016 3:38 PM, Shreyansh Jain wrote:
> > > > > Hi,
> > > > >
> > > > > (Apologies for overly-eager email sent on this thread earlier. Will
> be more
> > > > careful in future).
> > > > > This is more of a question/clarification than a comment. (And I have
> taken
> > > > only some snippets from original mail to keep it cleaner)
> > > > > <snip>
> > > > > > +MEMPOOL_REGISTER_OPS(ops_mp_mc);
> > > > > > +MEMPOOL_REGISTER_OPS(ops_sp_sc);
> > > > > > +MEMPOOL_REGISTER_OPS(ops_mp_sc);
> > > > > > +MEMPOOL_REGISTER_OPS(ops_sp_mc);
> > > > > <snip>
> > > > >
> > > > > From the above what I understand is that multiple packet pool
> handlers can
> > > > be created.
> > > > > I have a use-case where application has multiple pools but only the
> packet
> > > > pool is hardware backed. Using the hardware for general buffer
> requirements
> > > > would prove costly.
> > > > > From what I understand from the patch, selection of the pool is
> based on
> > > > the flags below.
> > > >
> > > > The flags are only used to select one of the default handlers for
> > > > backward compatibility through
> > > > the rte_mempool_create call. If you wish to use a mempool handler that
> > > > is not one of the
> > > > defaults, (i.e. a new hardware handler), you would use the
> > > > rte_create_mempool_empty
> > > > followed by the rte_mempool_set_ops_byname call.
> > > > So, for the external handlers, you create and empty mempool, then set
> > > > the operations (ops)
> > > > for that particular mempool.
> > > I am concerned about the existing applications (for example, l3fwd).
> > > Explicit calls to 'rte_create_mempool_empty->rte_mempool_set_ops_byname'
> model would require modifications to these applications.
> > > Ideally, without any modifications, these applications should be able to
> use packet pools (backed by hardware) and buffer pools (backed by
> ring/others) - transparently.
> > >
> > > If I go by your suggestions, what I understand is, doing the above
> without modification to applications would be equivalent to:
> > >
> > > struct rte_mempool_ops custom_hw_allocator = {...}
> > >
> > > thereafter, in config/common_base:
> > >
> > > CONFIG_RTE_DEFAULT_MEMPOOL_OPS="custom_hw_allocator"
> > >
> > > calls to rte_pktmbuf_pool_create would use the new allocator.
> >
> > Yes, correct. But only for calls to rte_pktmbuf_pool_create(). Calls to
> > rte_mempool_create will continue to use the default handlers (ring based).
> > > But, another problem arises here.
> > >
> > > There are two distinct paths for allocations of a memory pool:
> > > 1. A 'pkt' pool:
> > > rte_pktmbuf_pool_create
> > > \- rte_mempool_create_empty
> > > | \- rte_mempool_set_ops_byname(..ring_mp_mc..)
> > > |
> > > `- rte_mempool_set_ops_byname
> > > (...RTE_MBUF_DEFAULT_MEMPOOL_OPS..)
> > > /* Override default 'ring_mp_mc' of
> > > * rte_mempool_create */
> > >
> > > 2. Through generic mempool create API
> > > rte_mempool_create
> > > \- rte_mempool_create_empty
> > > (passing pktmbuf and pool constructors)
> > > I found various instances in example applications where
> rte_mempool_create() is being called directly for packet pools - bypassing
> the more semantically correct call to rte_pktmbuf_* for packet pools.
> > >
> > > In (2) control path, RTE_MBUF_DEFAULT_MEMPOOLS_OPS wouldn't be able to
> replace custom handler operations for packet buffer allocations.
> > >
> > > From a performance point-of-view, Applications should be able to select
> between packet pools and non-packet pools.
> >
> > This is intended for backward compatibility, and API consistency. Any
> > applications that use
> > rte_mempool_create directly will continue to use the default mempool
> > handlers. If the need
> > to use a custeom hander, they will need to be modified to call the newer
> > API,
> > rte_mempool_create_empty and rte_mempool_set_ops_byname.
> >
> >
> > > > > <snip>
> > > > > > + /*
> > > > > > + * Since we have 4 combinations of the SP/SC/MP/MC examine the
> flags to
> > > > > > + * set the correct index into the table of ops structs.
> > > > > > + */
> > > > > > + if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET))
> > > > > > + rte_mempool_set_ops_byname(mp, "ring_sp_sc");
> > > > > > + else if (flags & MEMPOOL_F_SP_PUT)
> > > > > > + rte_mempool_set_ops_byname(mp, "ring_sp_mc");
> > > > > > + else if (flags & MEMPOOL_F_SC_GET)
> > > > > > + rte_mempool_set_ops_byname(mp, "ring_mp_sc");
> > > > > > + else
> > > > > > + rte_mempool_set_ops_byname(mp, "ring_mp_mc");
> > > > > > +
> > > My suggestion is to have an additional flag, 'MEMPOOL_F_PKT_ALLOC',
> which, if specified, would:
> > >
> > > ...
> > > #define MEMPOOL_F_SC_GET 0x0008
> > > #define MEMPOOL_F_PKT_ALLOC 0x0010
> > > ...
> > >
> > > in rte_mempool_create_empty:
> > > ... after checking the other MEMPOOL_F_* flags...
> > >
> > > if (flags & MEMPOOL_F_PKT_ALLOC)
> > > rte_mempool_set_ops_byname(mp, RTE_MBUF_DEFAULT_MEMPOOL_OPS)
> > >
> > > And removing the redundant call to rte_mempool_set_ops_byname() in
> rte_pktmbuf_create_pool().
> > >
> > > Thereafter, rte_pktmbuf_pool_create can be changed to:
> > >
> > > ...
> > > mp = rte_mempool_create_empty(name, n, elt_size, cache_size,
> > > - sizeof(struct rte_pktmbuf_pool_private), socket_id, 0);
> > > + sizeof(struct rte_pktmbuf_pool_private), socket_id,
> > > + MEMPOOL_F_PKT_ALLOC);
> > > if (mp == NULL)
> > > return NULL;
> >
> > Yes, this would simplify somewhat the creation of a pktmbuf pool, in that
> it
> > replaces
> > the rte_mempool_set_ops_byname with a flag bit. However, I'm not sure we
> > want
> > to introduce a third method of creating a mempool to the developers. If we
> > introduced this, we would then have:
> > 1. rte_pktmbuf_pool_create()
> > 2. rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC set (which would
> > use the configured custom handler)
> > 3. rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC __not__ set followed
> > by a call to rte_mempool_set_ops_byname() (would allow several different
> > custom
> > handlers to be used in one application
> >
> > Does anyone else have an opinion on this? Oliver, Jerin, Jan?
>
> As I mentioned earlier, My take is not to create the separate API's for
> external mempool handlers.In my view, It's same, just that sepreate
> mempool handler through function pointers.
>
> To keep the backward compatibility, I think we can extend the flags
> in rte_mempool_create and have a single API external/internal pool
> creation(makes easy for existing applications too, add a just mempool
> flag command line argument to existing applications to choose the
> mempool handler)
May be I am interpreting it wrong, but, are you suggesting a single mempool handler for all buffer/packet needs of an application (passed as command line argument)?
That would be inefficient especially for cases where pool is backed by a hardware. The application wouldn't want its generic buffers to consume hardware resource which would be better used for packets.
I was hoping that external mempool handler would help segregate such use-cases and allow applications to tap into accelerated packet processors.
Do correct me if I my understanding is wrong.
>
> Jerin
>
> >
> > Regards,
> > Dave.
> >
> >
-
Shreyansh
next prev parent reply other threads:[~2016-06-09 11:49 UTC|newest]
Thread overview: 237+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 17:25 [dpdk-dev] [PATCH 0/5] add external mempool manager David Hunt
2016-01-26 17:25 ` [dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support David Hunt
2016-01-28 17:52 ` Jerin Jacob
2016-02-03 14:16 ` Hunt, David
2016-02-04 13:23 ` Jerin Jacob
2016-02-04 14:52 ` Olivier MATZ
2016-02-04 16:47 ` Hunt, David
2016-02-08 11:02 ` Olivier MATZ
2016-02-04 17:34 ` Hunt, David
2016-02-05 9:26 ` Olivier MATZ
2016-03-01 13:32 ` Hunt, David
2016-03-04 9:05 ` Olivier MATZ
2016-03-08 10:04 ` Hunt, David
2016-01-26 17:25 ` [dpdk-dev] [PATCH 2/5] memool: add stack (lifo) based external mempool handler David Hunt
2016-01-26 17:25 ` [dpdk-dev] [PATCH 3/5] mempool: add custom external mempool handler example David Hunt
2016-01-28 17:54 ` Jerin Jacob
2016-01-26 17:25 ` [dpdk-dev] [PATCH 4/5] mempool: add autotest for external mempool custom example David Hunt
2016-01-26 17:25 ` [dpdk-dev] [PATCH 5/5] mempool: allow rte_pktmbuf_pool_create switch between memool handlers David Hunt
2016-02-05 10:11 ` Olivier MATZ
2016-01-28 17:26 ` [dpdk-dev] [PATCH 0/5] add external mempool manager Jerin Jacob
2016-01-29 13:40 ` Hunt, David
2016-01-29 17:16 ` Jerin Jacob
2016-02-16 14:48 ` [dpdk-dev] [PATCH 0/6] " David Hunt
2016-02-16 14:48 ` [dpdk-dev] [PATCH 1/6] mempool: add external mempool manager support David Hunt
2016-02-16 19:27 ` [dpdk-dev] [dpdk-dev, " Jan Viktorin
2016-02-19 13:30 ` [dpdk-dev] [PATCH " Olivier MATZ
2016-02-29 11:11 ` Hunt, David
2016-03-04 9:04 ` Olivier MATZ
2016-02-16 14:48 ` [dpdk-dev] [PATCH 2/6] mempool: add stack (lifo) based external mempool handler David Hunt
2016-02-19 13:31 ` Olivier MATZ
2016-02-29 11:04 ` Hunt, David
2016-03-04 9:04 ` Olivier MATZ
2016-03-08 20:45 ` Venkatesan, Venky
2016-03-09 14:53 ` Olivier MATZ
2016-02-16 14:48 ` [dpdk-dev] [PATCH 3/6] mempool: adds a simple ring-based mempool handler using mallocs for objects David Hunt
2016-02-16 14:48 ` [dpdk-dev] [PATCH 4/6] mempool: add autotest for external mempool custom example David Hunt
2016-02-16 14:48 ` [dpdk-dev] [PATCH 5/6] mempool: allow rte_pktmbuf_pool_create switch between memool handlers David Hunt
2016-02-16 14:48 ` [dpdk-dev] [PATCH 6/6] mempool: add in the RTE_NEXT_ABI protection for ABI breakages David Hunt
2016-02-19 13:33 ` Olivier MATZ
2016-02-19 13:25 ` [dpdk-dev] [PATCH 0/6] external mempool manager Olivier MATZ
2016-02-29 10:55 ` Hunt, David
2016-03-09 9:50 ` [dpdk-dev] [PATCH v3 0/4] " David Hunt
2016-03-09 9:50 ` [dpdk-dev] [PATCH v3 1/4] mempool: add external mempool manager support David Hunt
2016-04-11 22:52 ` Yuanhan Liu
2016-03-09 9:50 ` [dpdk-dev] [PATCH v3 2/4] mempool: add custom mempool handler example David Hunt
2016-03-09 9:50 ` [dpdk-dev] [PATCH v3 3/4] mempool: allow rte_pktmbuf_pool_create switch between memool handlers David Hunt
2016-03-09 10:54 ` Panu Matilainen
2016-03-09 11:38 ` Hunt, David
2016-03-09 11:44 ` Panu Matilainen
2016-03-09 9:50 ` [dpdk-dev] [PATCH v3 4/4] mempool: add in the RTE_NEXT_ABI for ABI breakages David Hunt
2016-03-09 10:46 ` Panu Matilainen
2016-03-09 11:30 ` Hunt, David
2016-03-09 14:59 ` Olivier MATZ
2016-03-09 16:28 ` Hunt, David
2016-03-09 16:31 ` Olivier MATZ
2016-03-09 16:39 ` Hunt, David
2016-03-09 11:10 ` [dpdk-dev] [PATCH v3 0/4] external mempool manager Hunt, David
2016-04-11 22:46 ` Yuanhan Liu
2016-04-14 13:57 ` [dpdk-dev] [PATCH v4 0/3] " Olivier Matz
2016-04-14 13:57 ` [dpdk-dev] [PATCH v4 1/3] mempool: support external handler Olivier Matz
2016-04-14 13:57 ` [dpdk-dev] [PATCH v4 2/3] app/test: test external mempool handler Olivier Matz
2016-04-14 13:57 ` [dpdk-dev] [PATCH v4 3/3] mbuf: get default mempool handler from configuration Olivier Matz
2016-05-19 13:44 ` [dpdk-dev] mempool: external mempool manager David Hunt
2016-05-19 13:44 ` [dpdk-dev] [PATCH v5 1/3] mempool: support external handler David Hunt
2016-05-23 12:35 ` [dpdk-dev] [dpdk-dev,v5,1/3] " Jan Viktorin
2016-05-24 14:04 ` Hunt, David
2016-05-31 9:09 ` Hunt, David
2016-05-31 12:06 ` Jan Viktorin
2016-05-31 13:47 ` Hunt, David
2016-05-31 20:40 ` Olivier MATZ
2016-06-01 9:39 ` Hunt, David
2016-06-01 12:30 ` Jan Viktorin
2016-05-24 15:35 ` [dpdk-dev] [PATCH v5 1/3] " Jerin Jacob
2016-05-27 9:52 ` Hunt, David
2016-05-27 10:33 ` Jerin Jacob
2016-05-27 14:44 ` Hunt, David
2016-05-30 9:41 ` Jerin Jacob
2016-05-30 11:27 ` Hunt, David
2016-05-31 8:53 ` Jerin Jacob
2016-05-31 15:37 ` Hunt, David
2016-05-31 16:03 ` Jerin Jacob
2016-05-31 20:41 ` Olivier MATZ
2016-05-31 21:11 ` Jerin Jacob
2016-06-01 10:46 ` Hunt, David
2016-06-01 11:18 ` Jerin Jacob
2016-05-19 13:45 ` [dpdk-dev] [PATCH v5 2/3] app/test: test external mempool handler David Hunt
2016-05-23 12:45 ` [dpdk-dev] [dpdk-dev, v5, " Jan Viktorin
2016-05-31 9:17 ` Hunt, David
2016-05-31 12:14 ` Jan Viktorin
2016-05-31 20:40 ` Olivier MATZ
2016-05-19 13:45 ` [dpdk-dev] [PATCH v5 3/3] mbuf: get default mempool handler from configuration David Hunt
2016-05-23 12:40 ` [dpdk-dev] [dpdk-dev, v5, " Jan Viktorin
2016-05-31 9:26 ` Hunt, David
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 0/5] mempool: add external mempool manager David Hunt
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 1/5] mempool: support external handler David Hunt
2016-06-01 16:29 ` Hunt, David
2016-06-01 17:54 ` Jan Viktorin
2016-06-02 9:11 ` Hunt, David
2016-06-02 11:23 ` Hunt, David
2016-06-02 13:43 ` Jan Viktorin
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 2/5] mempool: remove rte_ring from rte_mempool struct David Hunt
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 3/5] mempool: add default external mempool handler David Hunt
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 4/5] app/test: test " David Hunt
2016-06-01 16:19 ` [dpdk-dev] [PATCH v6 5/5] mbuf: get default mempool handler from configuration David Hunt
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 0/5] mempool: add external mempool manager David Hunt
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations David Hunt
2016-06-02 13:38 ` [dpdk-dev] [PATCH v7 0/5] mempool: add external mempool manager Hunt, David
2016-06-03 6:38 ` [dpdk-dev] [PATCH v7 1/5] mempool: support external mempool operations Jerin Jacob
2016-06-03 10:28 ` Hunt, David
2016-06-03 10:49 ` Jerin Jacob
2016-06-03 11:07 ` Olivier MATZ
2016-06-03 11:42 ` Jan Viktorin
2016-06-03 12:10 ` Hunt, David
2016-06-03 12:28 ` Olivier MATZ
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 2/5] mempool: remove rte_ring from rte_mempool struct David Hunt
2016-06-03 12:28 ` Olivier MATZ
2016-06-03 14:17 ` Hunt, David
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 3/5] mempool: add default external mempool ops David Hunt
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 4/5] app/test: test external mempool manager David Hunt
2016-06-02 13:27 ` [dpdk-dev] [PATCH v7 5/5] mbuf: allow apps to change default mempool ops David Hunt
2016-06-03 12:28 ` Olivier MATZ
2016-06-03 14:06 ` Hunt, David
2016-06-03 14:10 ` Olivier Matz
2016-06-03 14:14 ` Hunt, David
2016-06-03 14:58 ` [dpdk-dev] [PATCH v8 0/5] mempool: add external mempool manager David Hunt
2016-06-03 14:58 ` [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool operations David Hunt
2016-06-06 14:32 ` Shreyansh Jain
2016-06-06 14:38 ` Shreyansh Jain
2016-06-07 9:25 ` Hunt, David
2016-06-08 13:48 ` Shreyansh Jain
2016-06-09 9:39 ` Hunt, David
2016-06-09 10:31 ` Jerin Jacob
2016-06-09 11:06 ` Hunt, David
2016-06-09 11:49 ` Shreyansh Jain [this message]
2016-06-09 12:30 ` Jerin Jacob
2016-06-09 13:03 ` Shreyansh Jain
2016-06-09 13:18 ` Hunt, David
2016-06-09 13:37 ` Jerin Jacob
2016-06-09 11:41 ` Shreyansh Jain
2016-06-09 12:55 ` Hunt, David
2016-06-09 13:09 ` Jan Viktorin
2016-06-10 7:29 ` Olivier Matz
2016-06-10 8:49 ` Jan Viktorin
2016-06-10 9:02 ` Hunt, David
2016-06-10 9:34 ` Hunt, David
2016-06-10 11:29 ` Shreyansh Jain
2016-06-10 11:13 ` Jerin Jacob
2016-06-10 11:37 ` Shreyansh Jain
2016-06-07 9:05 ` Shreyansh Jain
2016-06-08 12:13 ` Olivier Matz
2016-06-09 10:33 ` Hunt, David
2016-06-08 14:28 ` Shreyansh Jain
2016-06-03 14:58 ` [dpdk-dev] [PATCH v8 2/3] app/test: test external mempool manager David Hunt
2016-06-03 14:58 ` [dpdk-dev] [PATCH v8 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-10 15:16 ` [dpdk-dev] [PATCH v9 0/3] mempool: add external mempool manager David Hunt
2016-06-10 15:16 ` [dpdk-dev] [PATCH v9 1/3] mempool: support external mempool operations David Hunt
2016-06-13 12:16 ` Olivier Matz
2016-06-13 13:46 ` Hunt, David
2016-06-10 15:16 ` [dpdk-dev] [PATCH v9 2/3] app/test: test external mempool manager David Hunt
2016-06-10 15:16 ` [dpdk-dev] [PATCH v9 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-14 9:46 ` [dpdk-dev] [PATCH v10 0/3] mempool: add external mempool manager David Hunt
2016-06-14 9:46 ` [dpdk-dev] [PATCH v10 1/3] mempool: support external mempool operations David Hunt
2016-06-14 11:38 ` Shreyansh Jain
2016-06-14 12:55 ` Thomas Monjalon
2016-06-14 13:20 ` Hunt, David
2016-06-14 13:29 ` Thomas Monjalon
2016-06-14 9:46 ` [dpdk-dev] [PATCH v10 2/3] app/test: test external mempool manager David Hunt
2016-06-14 11:39 ` Shreyansh Jain
2016-06-14 9:46 ` [dpdk-dev] [PATCH v10 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-14 11:45 ` Shreyansh Jain
2016-06-14 12:32 ` [dpdk-dev] [PATCH v10 0/3] mempool: add external mempool manager Olivier MATZ
2016-06-14 15:48 ` [dpdk-dev] [PATCH v11 " David Hunt
2016-06-14 15:48 ` [dpdk-dev] [PATCH v11 1/3] mempool: support external mempool operations David Hunt
2016-06-14 16:08 ` Thomas Monjalon
2016-06-14 15:49 ` [dpdk-dev] [PATCH v11 2/3] app/test: test external mempool manager David Hunt
2016-06-14 15:49 ` [dpdk-dev] [PATCH v11 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-15 7:47 ` [dpdk-dev] [PATCH v12 0/3] mempool: add external mempool manager David Hunt
2016-06-15 7:47 ` [dpdk-dev] [PATCH v12 1/3] mempool: support external mempool operations David Hunt
2016-06-15 10:14 ` Jan Viktorin
2016-06-15 10:29 ` Hunt, David
2016-06-15 11:26 ` Jan Viktorin
2016-06-15 11:38 ` Thomas Monjalon
2016-06-15 7:47 ` [dpdk-dev] [PATCH v12 2/3] app/test: test external mempool manager David Hunt
2016-06-15 7:47 ` [dpdk-dev] [PATCH v12 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-15 10:13 ` [dpdk-dev] [PATCH v12 0/3] mempool: add external mempool manager Jan Viktorin
2016-06-15 11:47 ` Hunt, David
2016-06-15 12:03 ` Olivier MATZ
2016-06-15 12:38 ` Hunt, David
2016-06-15 13:50 ` Olivier MATZ
2016-06-15 14:02 ` Hunt, David
2016-06-15 14:10 ` Olivier MATZ
2016-06-15 14:47 ` Jan Viktorin
2016-06-15 16:03 ` Hunt, David
2016-06-15 16:34 ` Hunt, David
2016-06-15 16:40 ` Olivier MATZ
2016-06-16 4:35 ` Shreyansh Jain
2016-06-16 7:04 ` Hunt, David
2016-06-16 7:47 ` Hunt, David
2016-06-16 8:47 ` Olivier MATZ
2016-06-16 8:55 ` Hunt, David
2016-06-16 8:58 ` Olivier MATZ
2016-06-16 11:34 ` Hunt, David
2016-06-16 12:30 ` [dpdk-dev] [PATCH v13 " David Hunt
2016-06-16 12:30 ` [dpdk-dev] [PATCH v13 1/3] mempool: support external mempool operations David Hunt
2016-06-17 6:58 ` Hunt, David
2016-06-17 8:08 ` Olivier Matz
2016-06-17 8:42 ` Hunt, David
2016-06-17 9:09 ` Thomas Monjalon
2016-06-17 9:24 ` Hunt, David
2016-06-17 10:19 ` Olivier Matz
2016-06-17 10:18 ` Olivier Matz
2016-06-17 10:47 ` Hunt, David
2016-06-16 12:30 ` [dpdk-dev] [PATCH v13 2/3] app/test: test external mempool manager David Hunt
2016-06-16 12:30 ` [dpdk-dev] [PATCH v13 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-17 13:53 ` [dpdk-dev] [PATCH v14 0/3] mempool: add mempool handler feature David Hunt
2016-06-17 13:53 ` [dpdk-dev] [PATCH v14 1/3] mempool: support mempool handler operations David Hunt
2016-06-17 14:35 ` Jan Viktorin
2016-06-19 11:44 ` Hunt, David
2016-06-17 13:53 ` [dpdk-dev] [PATCH v14 2/3] app/test: test mempool handler David Hunt
2016-06-17 14:37 ` Jan Viktorin
2016-06-17 13:53 ` [dpdk-dev] [PATCH v14 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-17 14:41 ` Jan Viktorin
2016-06-19 12:05 ` [dpdk-dev] [PATCH v15 0/3] mempool: add mempool handler feature David Hunt
2016-06-19 12:05 ` [dpdk-dev] [PATCH v15 1/3] mempool: support mempool handler operations David Hunt
2016-06-19 12:05 ` [dpdk-dev] [PATCH v15 2/3] app/test: test mempool handler David Hunt
2016-06-19 12:05 ` [dpdk-dev] [PATCH v15 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-22 7:56 ` [dpdk-dev] [PATCH v15 0/3] mempool: add mempool handler feature Thomas Monjalon
2016-06-22 8:02 ` Thomas Monjalon
2016-06-22 9:27 ` [dpdk-dev] [PATCH v16 " David Hunt
2016-06-22 9:27 ` [dpdk-dev] [PATCH v16 1/3] mempool: support mempool handler operations David Hunt
2016-06-22 9:27 ` [dpdk-dev] [PATCH v16 2/3] app/test: test mempool handler David Hunt
2016-06-22 9:27 ` [dpdk-dev] [PATCH v16 3/3] mbuf: make default mempool ops configurable at build David Hunt
2016-06-23 21:22 ` [dpdk-dev] [PATCH v16 0/3] mempool: add mempool handler feature Thomas Monjalon
2016-06-24 4:55 ` Wiles, Keith
2016-06-24 11:20 ` Jan Viktorin
2016-06-24 11:24 ` Thomas Monjalon
2016-06-24 13:10 ` Jan Viktorin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR0401MB2061860D8DA2619EE63A367D905F0@VI1PR0401MB2061.eurprd04.prod.outlook.com \
--to=shreyansh.jain@nxp.com \
--cc=david.hunt@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=olivier.matz@6wind.com \
--cc=viktorin@rehivetech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).