[dpdk-dev] Clarification for - SoC specific driver based common sub component placing

[Hemant Agrawal]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, November 18, 2016 7:13 PM
> To: Hemant Agrawal 
> Cc: dev at dpdk.org
> Subject: Re: Clarification for - SoC specific driver based common sub 
> component
> placing
> 
> 2016-11-18 14:38, Thomas Monjalon:
> > 2016-11-18 12:44, Hemant Agrawal:
> > > We like to introduce NXP's DPAA (Data Path Acceleration Architecture Gen2)
> Poll mode drivers into the DPDK.
> > >
> > > We need some clarification w.r.t the right placing of some dependent
> components, which can be common across drivers. E.g. We have hardware
> queue and buffer manager driver. This will be used by both network driver and
> crypto driver. But it is specific to NXP platform only.
> > >
> > > What is the right place for such common hardware specific components in
> DPDK?
> > >   1. Add a new generic Soc library structure. e.g. librte_soc/nxp/. For 
> > > each
> soc configuration only the required components will be compiled-in.
> > >   2. Create a drivers/soc/nxp/dpaa2 structure to keep common driver libs.
> And link the network and crypto drivers to it.
> > >   3. Add it to main network driver and make the crypto driver dependent
> on it.
> >
> > Your question is more generic than SoC context.
> > You just want to share some code between drivers, right?
> > What about building a library located in drivers/common/nxp/ ?
> 
> I'm a bit reluctant to have company name in file hierarchy, as it not 
> something
> stable. And especially for NXP/Qualcomm...
> 
> In this case would it be better to name the directory drivers/common/dpaa2/ ?

[Hemant] Sounds good. 

Thanks! 

[dpdk-dev] Clarification for - SoC specific driver based common sub component placing

[Hemant Agrawal]

Hi all,

We like to introduce NXP's DPAA (Data Path Acceleration Architecture Gen2) Poll 
mode drivers into the DPDK.

We need some clarification w.r.t the right placing of some dependent 
components, which can be common across drivers. E.g. We have hardware queue and 
buffer manager driver. This will be used by both network driver and crypto 
driver. But it is specific to NXP platform only.

What is the right place for such common hardware specific components in DPDK? 
1. Add a new generic Soc library structure. e.g. librte_soc/nxp/. For 
each soc configuration only the required components will be compiled-in. 
2. Create a drivers/soc/nxp/dpaa2 structure to keep common driver libs. 
And link the network and crypto drivers to it.
3. Add it to main network driver and make the crypto driver dependent 
on it.

Regards,
Hemant

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> On Tue, Nov 15, 2016 at 09:34:16AM +0000, Hemant Agrawal wrote:
> > > On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > > > On Fri, Nov 11, 2016 at 10:34:39AM +, Hemant Agrawal wrote:
> > > > > Hi Neil,
> > > > >Pmdinfogen compiles with host compiler. It usages
> rte_byteorder.h
> > > of the target platform.
> > > > > However, if the host compiler is older than 4.8, it will be an issue 
> > > > > during
> cross
> > > compilation for some platforms.
> > > > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will 
> > > > > not
> > > understand the arm asm instructions.
> > > > >
> > > > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > >register uint16_t x = _x;
> > > > >asm volatile ("rev16 %0,%1"
> > > > > : "=r" (x)
> > > > > : "r" (x)
> > > > > );
> > > > >return x;
> > > > > }
> > > > > #endif
> > > > >
> > > > > One easy solution is that we add compiler platform check in this
> > > > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > > > >return (_x >> 8) | ((_x << 8) & 0xff00); } #else ?.
> > > > >
> > > > > Is there a better way to fix it?
> > > >
> > > > IMO, It is a HOST build infrastructure issue. If a host app is using
> > > > the dpdk service then it should compile and link against HOST
> > > > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > > > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> > > >
> > > > /Jerin
> > > >
> > > >
> > > That would be accurate.  That is to say, pmdinfogen is a tool that should 
> > > only
> be
> > > run on the host doing the build, by the host doing the build, and so 
> > > should be
> > > compiled to run on the host, not on the target being built for.
> > >
> > > Yeah, so what we need is a way to get to the host version of 
> > > rte_byteorder.h
> > > when building in a cross environment
> > >
> > +1
> >
> > > Neil
> >
> 
> Give this a try, I've tested it on linux, but not BSD.  From what I read the
> functions are not posix compliant, though they should exist on all BSD and 
> Linux
> systems in recent history.  There may be some fiddling needed for Net and
> OpenBSD variants, but I think this is the right general direction.

+ 1
This patch works good for Linux. 

> 
> 
> diff --git a/buildtools/pmdinfogen/pmdinfogen.h
> b/buildtools/pmdinfogen/pmdinfogen.h
> index 1da2966..c5ef89d 100644
> --- a/buildtools/pmdinfogen/pmdinfogen.h
> +++ b/buildtools/pmdinfogen/pmdinfogen.h
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
> 
>  /* On BSD-alike OSes elf.h defines these according to host's word size */
>  #undef ELF_ST_BIND
> @@ -75,9 +74,9 @@
>  #define CONVERT_NATIVE(fend, width, x) ({ \
>  typeof(x) ___x; \
>  if ((fend) == ELFDATA2LSB) \
> - ___x = rte_le_to_cpu_##width(x); \
> + ___x = le##width##toh(x); \
>  else \
> - ___x = rte_be_to_cpu_##width(x); \
> + ___x = be##width##toh(x); \
>   ___x; \
>  })
> 

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

> On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> > On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > > Hi Neil,
> > >Pmdinfogen compiles with host compiler. It usages 
> > > rte_byteorder.h
> of the target platform.
> > > However, if the host compiler is older than 4.8, it will be an issue 
> > > during cross
> compilation for some platforms.
> > > e.g. if we are compiling on x86 host for ARM, x86 host compiler will not
> understand the arm asm instructions.
> > >
> > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8)) static
> > > inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > >register uint16_t x = _x;
> > >asm volatile ("rev16 %0,%1"
> > > : "=r" (x)
> > > : "r" (x)
> > > );
> > >return x;
> > > }
> > > #endif
> > >
> > > One easy solution is that we add compiler platform check in this
> > > code section of rte_byteorder.h e.g #if !(defined __arm__ || defined
> > > __aarch64__) static inline uint16_t rte_arch_bswap16(uint16_t _x) {
> > >return (_x >> 8) | ((_x << 8) & 0xff00); } #else ?.
> > >
> > > Is there a better way to fix it?
> >
> > IMO, It is a HOST build infrastructure issue. If a host app is using
> > the dpdk service then it should compile and link against HOST
> > target(in this specific case, build/x86_64-native-linuxapp-gcc). I
> > think, introducing the HOSTTARGET kind of scheme is a clean solution.
> >
> > /Jerin
> >
> >
> That would be accurate.  That is to say, pmdinfogen is a tool that should 
> only be
> run on the host doing the build, by the host doing the build, and so should be
> compiled to run on the host, not on the target being built for.
> 
> Yeah, so what we need is a way to get to the host version of rte_byteorder.h
> when building in a cross environment
> 
+1 

> Neil

[dpdk-dev] [PATCH v2] mempool: Free memzone if mempool populate phys fails

[Hemant Agrawal]

From: Nipun Gupta 

This patch fixes the issue of memzone not being freed incase the
rte_mempool_populate_phys fails in the rte_mempool_populate_default

This issue was identified when testing with OVS ~2.6
- configure the system with low memory (e.g. < 500 MB)
- add bridge and dpdk interfaces
- delete brigde
- keep on repeating the above sequence.

Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")

Signed-off-by: Nipun Gupta 
---
 lib/librte_mempool/rte_mempool.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..aa513b9 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
mz->len, pg_sz,
rte_mempool_memchunk_mz_free,
(void *)(uintptr_t)mz);
-   if (ret < 0)
+   if (ret < 0) {
+   rte_memzone_free(mz);
goto fail;
+   }
}

return mp->size;
-- 
1.9.1

[dpdk-dev] [PATCH] mempool: Free memzone if mempool populate phys fails

[Hemant Agrawal]

From: Nipun Gupta 

This fixes the issue of memzone not being freed, if the
rte_mempool_populate_phys fails in the rte_mempool_populate_default

This issue was identified when testing with OVS ~2.6
- configure the system with low memory (e.g. < 500 MB)
- add bridge and dpdk interfaces
- delete brigde
- keep on repeating the above sequence.

Signed-off-by: Nipun Gupta 
---
 lib/librte_mempool/rte_mempool.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..aa513b9 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
mz->len, pg_sz,
rte_mempool_memchunk_mz_free,
(void *)(uintptr_t)mz);
-   if (ret < 0)
+   if (ret < 0) {
+   rte_memzone_free(mz);
goto fail;
+   }
}

return mp->size;
-- 
1.9.1

[dpdk-dev] pmdinfogen issues: cross compilation for ARM fails with older host compiler

[Hemant Agrawal]

Hi Neil,
   Pmdinfogen compiles with host compiler. It usages 
rte_byteorder.h of the target platform.
However, if the host compiler is older than 4.8, it will be an issue during 
cross compilation for some platforms.
e.g. if we are compiling on x86 host for ARM, x86 host compiler will not 
understand the arm asm instructions.

/* fix missing __builtin_bswap16 for gcc older then 4.8 */
#if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
   register uint16_t x = _x;
   asm volatile ("rev16 %0,%1"
: "=r" (x)
: "r" (x)
);
   return x;
}
#endif

One easy solution is that we add compiler platform check in this code section 
of rte_byteorder.h
e.g
#if !(defined __arm__ || defined __aarch64__)
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
   return (_x >> 8) | ((_x << 8) & 0xff00);
}
#else ?.

Is there a better way to fix it?

Regards,
Hemant


From: Michael Wildt [mailto:michael.wi...@broadcom.com]
Sent: Wednesday, September 14, 2016 7:18 PM
To: Hemant Agrawal 
Cc: Thomas Monjalon ; users at dpdk.org
Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and 
pmdinfogen issues

Hi Hemant,

Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but 
good to know.

I gave that one a try and that works as well but as with the 5.3 I have to be 
on a Ubuntu not RHEL6 to make it work.

Thanks,
Michael

On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal mailto:hemant.agrawal at nxp.com>> wrote:
Hi Michael,
One of the problem, I found with Linaro gcc 4.9 toolchain for i686 
(default one), that it seems to be built with older kernel headers (<3.8). This 
usages older linux/vhost.h file.

However, we have not observed this issue with x86_64 based toolchain on 64 bit 
m/c.
 
https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/

Regards,
Hemant

> -Original Message-
> From: users [mailto:users-bounces at dpdk.org<mailto:users-bounces at 
> dpdk.org>] On Behalf Of Michael Wildt
> Sent: Wednesday, September 14, 2016 12:05 AM
> To: Thomas Monjalon mailto:thomas.monjalon at 
> 6wind.com>>
> Cc: users at dpdk.org<mailto:users at dpdk.org>
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost 
> and
> pmdinfogen issues
>
> Hi Thomas,
>
> The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> application. Its actually 4.9.2.
>
> Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> points to arm's version, but pmdinfogen builds.
>
> Probably should still fix both issues just to keep the base clean.
>
> At least I have a workaround in the interim.
>
> Thanks for the help.
>
> Thanks,
> Michael
>
>
> On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> mailto:thomas.monjalon at 6wind.com>
> > wrote:
>
> > 2016-09-13 07:45, Michael Wildt:
> > > Hi Thomas,
> > >
> > > Appreciate the assistance. Please see inline.
> > >
> > >
> > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > thomas.monjalon at 6wind.com<mailto:thomas.monjalon at 6wind.com>>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > 2016-09-12 22:20, Michael Wildt:
> > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > This
> > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > compiling
> > > > > natively there are no issues.
> > > >
> > > > Your analysis below seems good.
> > > > Interestingly, I do not see such error (don't know why).
> > > > Please could you share the commands you are using?
> > > >
> > >
> > > Sure can.
> > >
> > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64
> > >
> > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > >
> > > > > - librte_vhost, fails with:
> > > > >
> > > > > /pr

[dpdk-dev] [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

Hi Olivier,

> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Friday, October 14, 2016 5:41 PM
> > On 9/22/2016 6:42 PM, Hemant Agrawal wrote:
> >> Hi Olivier
> >>
> >> On 9/19/2016 7:27 PM, Olivier Matz wrote:
> >>> Hi Hemant,
> >>>
> >>> On 09/16/2016 06:46 PM, Hemant Agrawal wrote:
> >>>> In the rte_pktmbuf_pool_create, if the default external mempool is
> >>>> not available, the implementation can default to "ring_mp_mc",
> >>>> which is an software implementation.
> >>>>
> >>>> Signed-off-by: Hemant Agrawal 
> >>>> ---
> >>>> Changes in V3:
> >>>> * adding warning message to say that falling back to default sw
> >>>> pool
> >>>> ---
> >>>>  lib/librte_mbuf/rte_mbuf.c | 8 
> >>>>  1 file changed, 8 insertions(+)
> >>>>
> >>>> diff --git a/lib/librte_mbuf/rte_mbuf.c
> >>>> b/lib/librte_mbuf/rte_mbuf.c index 4846b89..8ab0eb1 100644
> >>>> --- a/lib/librte_mbuf/rte_mbuf.c
> >>>> +++ b/lib/librte_mbuf/rte_mbuf.c
> >>>> @@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name,
> >>>> unsigned n,
> >>>>
> >>>>  rte_errno = rte_mempool_set_ops_byname(mp,
> >>>>  RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
> >>>> +
> >>>> +/* on error, try falling back to the software based default
> >>>> pool */
> >>>> +if (rte_errno == -EOPNOTSUPP) {
> >>>> +RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
> >>>> +"falling back to sw mempool \"ring_mp_mc\"");
> >>>> +rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc",
> >>>> NULL);
> >>>> +}
> >>>> +
> >>>>  if (rte_errno != 0) {
> >>>>  RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
> >>>>  return NULL;
> >>>>
> >>>
> >>> Without adding a new method ".supported()", the first call to
> >>> rte_mempool_populate() could return the same error ENOTSUP. In this
> >>> case, it is still possible to fallback.
> >>>
> >> It will be bit late.
> >>
> >> On failure, than we have to set the default ops and do a goto before
> >> rte_pktmbuf_pool_init(mp, _priv);
> 
> I still think we can do the job without adding the .supported() method.
> The following code is just an (untested) example:
> 
> struct rte_mempool *
> rte_pktmbuf_pool_create(const char *name, unsigned n,
> unsigned cache_size, uint16_t priv_size, uint16_t data_room_size,
> int socket_id)
> {
> struct rte_mempool *mp;
> struct rte_pktmbuf_pool_private mbp_priv;
> unsigned elt_size;
> int ret;
> const char *ops[] = {
> RTE_MBUF_DEFAULT_MEMPOOL_OPS, "ring_mp_mc", NULL,
> };
> const char **op;
> 
> if (RTE_ALIGN(priv_size, RTE_MBUF_PRIV_ALIGN) != priv_size) {
> RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n",
> priv_size);
> rte_errno = EINVAL;
> return NULL;
> }
> elt_size = sizeof(struct rte_mbuf) + (unsigned)priv_size +
> (unsigned)data_room_size;
> mbp_priv.mbuf_data_room_size = data_room_size;
> mbp_priv.mbuf_priv_size = priv_size;
> 
> for (op = [0]; *op != NULL; op++) {
> mp = rte_mempool_create_empty(name, n, elt_size, cache_size,
> sizeof(struct rte_pktmbuf_pool_private), socket_id, 0);
> if (mp == NULL)
> return NULL;
> 
> ret = rte_mempool_set_ops_byname(mp, *op, NULL);
> if (ret != 0) {
> RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
> rte_mempool_free(mp);
> if (ret == -ENOTSUP)
> continue;
> rte_errno = -ret;
> return NULL;
> }
> rte_pktmbuf_pool_init(mp, _priv);
> 
> ret = rte_mempool_populate_default(mp);
> if (ret < 0) {
> rte_mempool_free(mp);
> if (ret == -ENOTSUP)
> continue;
> rte_errno = -ret;
> return NULL;
> }
> }
> 
> rte_mempool_obj_iter(mp, rte_pktmbuf_init, NULL);
> 
> return mp;
> }
> 
> 

[dpdk-dev] [PATCHv3] examples/l3fwd: em: use hw accelerated crc hash function for arm64

[Hemant Agrawal]

if machine level CRC extension are available, offload the
hash to machine provide functions e.g. armv8-a CRC extensions
support it

Signed-off-by: Hemant Agrawal 
Reviewed-by: Jerin Jacob 
---
 examples/l3fwd/l3fwd_em.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 89a68e6..9cc4460 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -57,13 +57,17 @@

 #include "l3fwd.h"

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
+#define EM_HASH_CRC 1
+#endif
+
+#ifdef EM_HASH_CRC
 #include 
 #define DEFAULT_HASH_FUNC   rte_hash_crc
 #else
 #include 
 #define DEFAULT_HASH_FUNC   rte_jhash
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

 #define IPV6_ADDR_LEN 16

@@ -168,17 +172,17 @@ ipv4_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
init_val = rte_hash_crc_4byte(t, init_val);
init_val = rte_hash_crc_4byte(k->ip_src, init_val);
init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash_1word(k->ip_src, init_val);
init_val = rte_jhash_1word(k->ip_dst, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

return init_val;
 }
@@ -190,16 +194,16 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
const union ipv6_5tuple_host *k;
uint32_t t;
const uint32_t *p;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
const uint32_t  *ip_src0, *ip_src1, *ip_src2, *ip_src3;
const uint32_t  *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3;
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

k = data;
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
ip_src0 = (const uint32_t *) k->ip_src;
ip_src1 = (const uint32_t *)(k->ip_src+4);
ip_src2 = (const uint32_t *)(k->ip_src+8);
@@ -218,14 +222,14 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash(k->ip_src,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash(k->ip_dst,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
 }

-- 
1.9.1

[dpdk-dev] [PATCH v2] examples/l3fwd: em: use hw accelerated crc hash function for arm64

[Hemant Agrawal]

On 10/13/2016 7:06 PM, Jerin Jacob wrote:
> On Fri, Oct 14, 2016 at 12:17:05AM +0530, Hemant Agrawal wrote:
>> if machine level CRC extension are available, offload the
>> hash to machine provide functions e.g. armv8-a CRC extensions
>> support it
>>
>> Signed-off-by: Hemant Agrawal 
>> Reviewed-by: Jerin Jacob 
>> ---
>>  examples/l3fwd/l3fwd_em.c | 24 ++--
>>  1 file changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
>> index 89a68e6..d92d0aa 100644
>> --- a/examples/l3fwd/l3fwd_em.c
>> +++ b/examples/l3fwd/l3fwd_em.c
>> @@ -57,13 +57,17 @@
>>
>>  #include "l3fwd.h"
>>
>> -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
>> +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) && 
>> defined(RTE_MACHINE_CPUFLAG_CRC32)
>
> The will evaluate as FALSE always.
>
> Please change to logical OR operation here. ie #if 
> defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> defined(RTE_MACHINE_CPUFLAG_CRC32)
>
Oops! Will fix it.

>> +#define EM_HASH_CRC 1
>> +#endif
>

[dpdk-dev] [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK

[Hemant Agrawal]

 Hi Bill/Jerin,

> 
> Thanks for the review.
> 
> [snip]
> > > + * If the device init operation is successful, the correspondence
> > > + between
> > > + * the device identifier assigned to the new device and its
> > > + associated
> > > + * *rte_event_dev* structure is effectively registered.
> > > + * Otherwise, both the *rte_event_dev* structure and the device
> > > identifier are
> > > + * freed.
> > > + *
> > > + * The functions exported by the application Event API to setup a
> > > + device
> > > + * designated by its device identifier must be invoked in the
> > > + following
> > > order:
> > > + * - rte_event_dev_configure()
> > > + * - rte_event_queue_setup()
> > > + * - rte_event_port_setup()
> > > + * - rte_event_port_link()
> > > + * - rte_event_dev_start()
> > > + *
> > > + * Then, the application can invoke, in any order, the functions
> > > + * exported by the Event API to schedule events, dequeue events,
> > > + enqueue
> > > events,
> > > + * change event queue(s) to event port [un]link establishment and so on.
> > > + *
> > > + * Application may use rte_event_[queue/port]_default_conf_get() to
> > > + get
> > > the
> > > + * default configuration to set up an event queue or event port by
> > > + * overriding few default values.
> > > + *
> > > + * If the application wants to change the configuration (i.e. call
> > > + * rte_event_dev_configure(), rte_event_queue_setup(), or
> > > + * rte_event_port_setup()), it must call rte_event_dev_stop() first
> > > + to
> > > stop the
> > > + * device and then do the reconfiguration before calling
> > > rte_event_dev_start()
> > > + * again. The schedule, enqueue and dequeue functions should not be
> > > invoked
> > > + * when the device is stopped.
> > >
> >
> > Given this requirement, the question is what happens to events that
> > are "in flight" at the time rte_event_dev_stop() is called? Is stop an
> > asynchronous operation that quiesces the event _dev and allows
> > in-flight events to drain from queues/ports prior to fully stopping,
> > or is some sort of separate explicit quiesce mechanism required? If
> > stop is synchronous and simply halts the event_dev, then how is an
> > application to know if subsequent configure/setup calls would leave
> > these pending events with no place to stand?
> >
> 
> From an application API perspective rte_event_dev_stop() is a synchronous
> function.
> If the stop has been called for re-configuring the number of queues, ports 
> etc of
> the device, then "in flight" entry preservation will be implementation 
> defined.
> else "in flight" entries will be preserved.
> 
> [snip]
> 
> > > +extern int
> > > +rte_event_dev_socket_id(uint8_t dev_id);
> > > +
> > > +/* Event device capability bitmap flags */
> > > +#define RTE_EVENT_DEV_CAP_QUEUE_QOS(1 << 0)
> > > +/**< Event scheduling prioritization is based on the priority
> > > +associated
> > > with
> > > + *  each event queue.
> > > + *
> > > + *  \see rte_event_queue_setup(), RTE_EVENT_QUEUE_PRIORITY_NORMAL
> > > +*/
> > > +#define RTE_EVENT_DEV_CAP_EVENT_QOS(1 << 1)
> > > +/**< Event scheduling prioritization is based on the priority
> > > +associated
> > > with
> > > + *  each event. Priority of each event is supplied in *rte_event*
> > > structure
> > > + *  on each enqueue operation.
> > > + *
> > > + *  \see rte_event_enqueue()
> > > + */
> > > +
> > > +/**
> > > + * Event device information
> > > + */
> > > +struct rte_event_dev_info {
> > > +   const char *driver_name;/**< Event driver name */
> > > +   struct rte_pci_device *pci_dev; /**< PCI information */
> > > +   uint32_t min_dequeue_wait_ns;
> > > +   /**< Minimum supported global dequeue wait delay(ns) by this
> > > device */
> > > +   uint32_t max_dequeue_wait_ns;
> > > +   /**< Maximum supported global dequeue wait delay(ns) by this
> > > device */
> > > +   uint32_t dequeue_wait_ns;
> > >
> >
> > Am I reading this correctly that there is no way to support an
> > indefinite waiting capability? Or is this just saying that if a timed
> > wait is performed there are min/max limits for the wait duration?
> 
> Application can wait indefinite if required. see
> RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration option.
> 
> Trivial application may not need different wait values on each dequeue.This 
> is a
> performance optimization opportunity for implementation.

 Jerin, It is irrespective of wait configuration, whether you are using per 
device wait or per dequeuer wait. 
 Can the value of MAX_U32 or MAX_U64 be treated as infinite weight? 

> 
> >
> >
> > > +   /**< Configured global dequeue wait delay(ns) for this device */
> > > +   uint8_t max_event_queues;
> > > +   /**< Maximum event_queues supported by this device */
> > > +   uint32_t max_event_queue_flows;
> > > +   /**< Maximum supported flows in an event queue by this device*/
> > > +   uint8_t max_event_queue_priority_levels;
> > > +   

[dpdk-dev] [PATCH v2] examples/l3fwd: em: use hw accelerated crc hash function for arm64

[Hemant Agrawal]

if machine level CRC extension are available, offload the
hash to machine provide functions e.g. armv8-a CRC extensions
support it

Signed-off-by: Hemant Agrawal 
Reviewed-by: Jerin Jacob 
---
 examples/l3fwd/l3fwd_em.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 89a68e6..d92d0aa 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -57,13 +57,17 @@

 #include "l3fwd.h"

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) && defined(RTE_MACHINE_CPUFLAG_CRC32)
+#define EM_HASH_CRC 1
+#endif
+
+#ifdef EM_HASH_CRC
 #include 
 #define DEFAULT_HASH_FUNC   rte_hash_crc
 #else
 #include 
 #define DEFAULT_HASH_FUNC   rte_jhash
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

 #define IPV6_ADDR_LEN 16

@@ -168,17 +172,17 @@ ipv4_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
init_val = rte_hash_crc_4byte(t, init_val);
init_val = rte_hash_crc_4byte(k->ip_src, init_val);
init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash_1word(k->ip_src, init_val);
init_val = rte_jhash_1word(k->ip_dst, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

return init_val;
 }
@@ -190,16 +194,16 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
const union ipv6_5tuple_host *k;
uint32_t t;
const uint32_t *p;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
const uint32_t  *ip_src0, *ip_src1, *ip_src2, *ip_src3;
const uint32_t  *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3;
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

k = data;
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#ifdef EM_HASH_CRC
ip_src0 = (const uint32_t *) k->ip_src;
ip_src1 = (const uint32_t *)(k->ip_src+4);
ip_src2 = (const uint32_t *)(k->ip_src+8);
@@ -218,14 +222,14 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash(k->ip_src,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash(k->ip_dst,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
 }

-- 
1.9.1

[dpdk-dev] [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

Hi Olivier,
Any updates w.r.t this patch set?

Regards
Hemant
On 9/22/2016 6:42 PM, Hemant Agrawal wrote:
> Hi Olivier
>
> On 9/19/2016 7:27 PM, Olivier Matz wrote:
>> Hi Hemant,
>>
>> On 09/16/2016 06:46 PM, Hemant Agrawal wrote:
>>> In the rte_pktmbuf_pool_create, if the default external mempool is
>>> not available, the implementation can default to "ring_mp_mc", which
>>> is an software implementation.
>>>
>>> Signed-off-by: Hemant Agrawal 
>>> ---
>>> Changes in V3:
>>> * adding warning message to say that falling back to default sw pool
>>> ---
>>>  lib/librte_mbuf/rte_mbuf.c | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>>> index 4846b89..8ab0eb1 100644
>>> --- a/lib/librte_mbuf/rte_mbuf.c
>>> +++ b/lib/librte_mbuf/rte_mbuf.c
>>> @@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name,
>>> unsigned n,
>>>
>>>  rte_errno = rte_mempool_set_ops_byname(mp,
>>>  RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
>>> +
>>> +/* on error, try falling back to the software based default pool */
>>> +if (rte_errno == -EOPNOTSUPP) {
>>> +RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
>>> +"falling back to sw mempool \"ring_mp_mc\"");
>>> +rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
>>> +}
>>> +
>>>  if (rte_errno != 0) {
>>>  RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
>>>  return NULL;
>>>
>>
>> Without adding a new method ".supported()", the first call to
>> rte_mempool_populate() could return the same error ENOTSUP. In this
>> case, it is still possible to fallback.
>>
> It will be bit late.
>
> On failure, than we have to set the default ops and do a goto before
> rte_pktmbuf_pool_init(mp, _priv);
>
>
>> I've just submitted an RFC, which I think is quite linked:
>> http://dpdk.org/ml/archives/dev/2016-September/046974.html
>> Assuming a new parameter "mempool_ops" is added to
>> rte_pktmbuf_pool_create(), would it make sense to fallback to
>> "ring_mp_mc"? What about just returning ENOTSUP? The application could
>> do the job and decide which sw fallback to use.
>
> We ran into this issue when trying to run the standard DPDK examples
> (l3fwd) in VM. Do you think, is it practical to add fallback handling in
> each of the DPDK examples?
>
> Typically when someone is writing a application on host, he need not
> worry non-availability of the hw offloaded mempool. He may also want to
> run the same binary in virtual machine. In VM, it is not guaranteed that
> hw offloaded mempools will be available.
>
> w.r.t your RFC, we can do this:
> if the user has specified a mempool_ops in rte_pktmbuf_pool_create(),
> don't fallback. It will be responsibility for application to decide on
> calling again rte_pktmbuf_pool_create() with different mempool_ops.
>
>>
>>
>> Regards,
>> Olivier
>>
>
>
>

[dpdk-dev] [RFC] libeventdev: event driven programming model framework for DPDK

[Hemant Agrawal]

Hi Jerin/Narender,

Thanks for the proposal and discussions. 

I agree with many of the comment made by Narender.  Here are some 
additional comments.

1. rte_event_schedule - should support option for bulk dequeue. The size of 
bulk should be a property of device, how much depth it can support.

2. The event schedule should also support the option to specify the amount of 
time, it can wait. The implementation may only support global 
setting(dequeue_wait_ns) for wait time. They can take any non-zero wait value 
as to implement wait.  

3. rte_event_schedule_from_group - there should be one model.  Both Push and 
Pull may not work well together. At least the simultaneous mixed config will 
not work on NXP hardware scheduler. 

4. Priority of queues within the scheduling group?  - Please keep in mind that 
some hardware supports intra scheduler priority and some only support intra 
flow_queue priority within a scheduler instance. The events of same flow id 
should have same priority.

5. w.r.t flow_queue numbers in log2, I will prefer to have absolute number. Not 
all system may have large number of queues. So the design should keep in 
account the system will fewer number of queues.

Regards,
Hemant

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Wednesday, October 05, 2016 12:55 PM
> On Tue, Oct 04, 2016 at 09:49:52PM +, Vangati, Narender wrote:
> > Hi Jerin,
> 
> Hi Narender,
> 
> Thanks for the comments.I agree with proposed changes; I will address these
> comments in v2.
> 
> /Jerin
> 
> 
> >
> >
> >
> > Here are some comments on the libeventdev RFC.
> >
> > These are collated thoughts after discussions with you & others to 
> > understand
> the concepts and rationale for the current proposal.
> >
> >
> >
> > 1. Concept of flow queues. This is better abstracted as flow ids and not as 
> > flow
> queues which implies there is a queueing structure per flow. A s/w
> implementation can do atomic load balancing on multiple flow ids more
> efficiently than maintaining each event in a specific flow queue.
> >
> >
> >
> > 2. Scheduling group. A scheduling group is more a steam of events, so an 
> > event
> queue might be a better abstraction.
> >
> >
> >
> > 3. An event queue should support the concept of max active atomic flows
> (maximum number of active flows this queue can track at any given time) and
> max active ordered sequences (maximum number of outstanding events waiting
> to be egress reordered by this queue). This allows a scheduler implementation 
> to
> dimension/partition its resources among event queues.
> >
> >
> >
> > 4. An event queue should support concept of a single consumer. In an
> application, a stream of events may need to be brought together to a single
> core for some stages of processing, e.g. for TX at the end of the pipeline to
> avoid NIC reordering of the packets. Having a 'single consumer' event queue 
> for
> that stage allows the intensive scheduling logic to be short circuited and can
> improve throughput for s/w implementations.
> >
> >
> >
> > 5. Instead of tying eventdev access to an lcore, a higher level of 
> > abstraction
> called event port is needed which is the application i/f to the eventdev. 
> Event
> ports are connected to event queues and is the object the application uses to
> dequeue and enqueue events. There can be more than one event port per lcore
> allowing multiple lightweight threads to have their own i/f into eventdev, if 
> the
> implementation supports it. An event port abstraction also encapsulates
> dequeue depth and enqueue depth for a scheduler implementations which can
> schedule multiple events at a time and output events that can be buffered.
> >
> >
> >
> > 6. An event should support priority. Per event priority is useful for 
> > segregating
> high priority (control messages) traffic from low priority within the same 
> flow.
> This needs to be part of the event definition for implementations which 
> support
> it.
> >
> >
> >
> > 7. Event port to event queue servicing priority. This allows two event 
> > ports to
> connect to the same event queue with different priorities. For implementations
> which support it, this allows a worker core to participate in two different
> workflows with different priorities (workflow 1 needing 3.5 cores, workflow 2
> needing 2.5 cores, and so on).
> >
> >
> >
> > 8. Define the workflow as schedule/dequeue/enqueue. An implementation is
> free to define schedule as NOOP. A distributed s/w scheduler can use this to
> schedule events; also a centralized s/w scheduler can make this a NOOP on non-
> scheduler cores.
> >
> >
> >
> > 9. The schedule_from_group API does not fit the workflow.
> >
> >
> >
> > 10. The ctxt_update/ctxt_wait breaks the normal workflow. If the normal
> workflow is a dequeue -> do work based on event type -> enqueue,  a pin_event
> argument to enqueue (where the pinned event is returned through the normal
> 

[dpdk-dev] [PATCH] examples/l3fwd: em path hash offload to machine

[Hemant Agrawal]

Hi Jerin,
Thanks for the review, I will send a v2 with the suggestions made
Regards,
Hemant

> -Original Message-
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Wednesday, October 05, 2016 5:23 PM
> To: Hemant Agrawal 
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: em path hash offload to
> machine
> 
> On Tue, Aug 23, 2016 at 08:24:39PM +0530, Hemant Agrawal wrote:
> 
> Maybe you can change the subject line to:
> examples/l3fwd: em: use hw accelerated crc hash function for arm64 instead of:
> examples/l3fwd: em path hash offload to machine
> 
> > if machine level CRC extension are available, offload the hash to
> > machine provided functions e.g. armv8-a CRC extensions support it
> >
> > Signed-off-by: Hemant Agrawal 
> > ---
> >  examples/l3fwd/l3fwd_em.c | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
> > index def5a02..a889c67 100644
> > --- a/examples/l3fwd/l3fwd_em.c
> > +++ b/examples/l3fwd/l3fwd_em.c
> > @@ -58,13 +58,13 @@
> >
> >  #include "l3fwd.h"
> >
> > -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> > +defined(RTE_MACHINE_CPUFLAG_CRC32)
> 
> Rather than adding new compilation flag everywhere, Maybe you can add
> 
> #if defined(RTE_MACHINE_CPUFLAG_SSE4_2) &&
> defined(RTE_MACHINE_CPUFLAG_CRC32)
> #define EM_HASH_CRC 1
> #endif
> 
> something like above to reduce the change for future platforms with crc
> support.
> 
> Other than that, you can add:
> Reviewed-by: Jerin Jacob 
> 
> >  #include 
> >  #define DEFAULT_HASH_FUNC   rte_hash_crc
> >  #else
> >  #include 
> >  #define DEFAULT_HASH_FUNC   rte_jhash
> > -#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#endif
> >
> >  #define IPV6_ADDR_LEN 16
> >
> > @@ -169,17 +169,17 @@ ipv4_hash_crc(const void *data, __rte_unused
> uint32_t data_len,
> > t = k->proto;
> > p = (const uint32_t *)>port_src;
> >
> > -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> > +defined(RTE_MACHINE_CPUFLAG_CRC32)
> > init_val = rte_hash_crc_4byte(t, init_val);
> > init_val = rte_hash_crc_4byte(k->ip_src, init_val);
> > init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
> > init_val = rte_hash_crc_4byte(*p, init_val); -#else /*
> > RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#else
> > init_val = rte_jhash_1word(t, init_val);
> > init_val = rte_jhash_1word(k->ip_src, init_val);
> > init_val = rte_jhash_1word(k->ip_dst, init_val);
> > init_val = rte_jhash_1word(*p, init_val); -#endif /*
> > RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#endif
> >
> > return init_val;
> >  }
> > @@ -191,16 +191,16 @@ ipv6_hash_crc(const void *data, __rte_unused
> uint32_t data_len,
> > const union ipv6_5tuple_host *k;
> > uint32_t t;
> > const uint32_t *p;
> > -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> > +defined(RTE_MACHINE_CPUFLAG_CRC32)
> > const uint32_t  *ip_src0, *ip_src1, *ip_src2, *ip_src3;
> > const uint32_t  *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3; -#endif /*
> > RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#endif
> >
> > k = data;
> > t = k->proto;
> > p = (const uint32_t *)>port_src;
> >
> > -#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > +#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) ||
> > +defined(RTE_MACHINE_CPUFLAG_CRC32)
> > ip_src0 = (const uint32_t *) k->ip_src;
> > ip_src1 = (const uint32_t *)(k->ip_src+4);
> > ip_src2 = (const uint32_t *)(k->ip_src+8); @@ -219,14 +219,14 @@
> > ipv6_hash_crc(const void *data, __rte_unused uint32_t data_len,
> > init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
> > init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
> > init_val = rte_hash_crc_4byte(*p, init_val); -#else /*
> > RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#else
> > init_val = rte_jhash_1word(t, init_val);
> > init_val = rte_jhash(k->ip_src,
> > sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
> > init_val = rte_jhash(k->ip_dst,
> > sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
> > init_val = rte_jhash_1word(*p, init_val); -#endif /*
> > RTE_MACHINE_CPUFLAG_SSE4_2 */
> > +#endif
> > return init_val;
> >  }
> >
> > --
> > 1.9.1
> >

[dpdk-dev] [RFC 0/7] changing mbuf pool handler

[Hemant Agrawal]

Hi Olivier,

> -Original Message-
> From: Hunt, David [mailto:david.hunt at intel.com]
> Hi Olivier,
> 
> 
> On 3/10/2016 4:49 PM, Olivier Matz wrote:
> > Hi Hemant,
> >
> > Thank you for your feedback.
> >
> > On 09/22/2016 01:52 PM, Hemant Agrawal wrote:
> >> Hi Olivier
> >>
> >> On 9/19/2016 7:12 PM, Olivier Matz wrote:
> >>> Hello,
> >>>
> >>> Following discussion from [1] ("usages issue with external mempool").
> >>>
> >>> This is a tentative to make the mempool_ops feature introduced by
> >>> David Hunt [2] more widely used by applications.
> >>>
> >>> It applies on top of a minor fix in mbuf lib [3].
> >>>
> >>> To sumarize the needs (please comment if I did not got it properly):
> >>>
> >>> - new hw-assisted mempool handlers will soon be introduced
> >>> - to make use of it, the new mempool API [4]
> (rte_mempool_create_empty,
> >>>rte_mempool_populate, ...) has to be used
> >>> - the legacy mempool API (rte_mempool_create) does not allow to
> change
> >>>the mempool ops. The default is "ring_<s|m>p_<s|m>c" depending on
> >>>flags.
> >>> - the mbuf helper (rte_pktmbuf_pool_create) does not allow to change
> >>>them either, and the default is RTE_MBUF_DEFAULT_MEMPOOL_OPS
> >>>("ring_mp_mc")
> >>> - today, most (if not all) applications and examples use either
> >>>rte_pktmbuf_pool_create or rte_mempool_create to create the mbuf
> >>>pool, making it difficult to take advantage of this feature with
> >>>existing apps.
> >>>
> >>> My initial idea was to deprecate both rte_pktmbuf_pool_create() and
> >>> rte_mempool_create(), forcing the applications to use the new API,
> >>> which is more flexible. But after digging a bit, it appeared that
> >>> rte_mempool_create() is widely used, and not only for mbufs.
> >>> Deprecating it would have a big impact on applications, and
> >>> replacing it with the new API would be overkill in many use-cases.
> >> I agree with the proposal.
> >>
> >>> So I finally tried the following approach (inspired from a
> >>> suggestion Jerin [5]):
> >>>
> >>> - add a new mempool_ops parameter to rte_pktmbuf_pool_create().
> This
> >>>unfortunatelly breaks the API, but I implemented an ABI compat layer.
> >>>If the patch is accepted, we could discuss how to announce/schedule
> >>>the API change.
> >>> - update the applications and documentation to prefer
> >>>rte_pktmbuf_pool_create() as much as possible
> >>> - update most used examples (testpmd, l2fwd, l3fwd) to add a new
> command
> >>>line argument to select the mempool handler
> >>>
> >>> I hope the external applications would then switch to
> >>> rte_pktmbuf_pool_create(), since it supports most of the use-cases
> >>> (even priv_size != 0, since we can call rte_mempool_obj_iter() after) .
> >>>
> >> I will still prefer if you can add the "rte_mempool_obj_cb_t *obj_cb,
> >> void *obj_cb_arg" into "rte_pktmbuf_pool_create". This single
> >> consolidated wrapper will almost make it certain that applications
> >> will not try to use rte_mempool_create for packet buffers.
> > The patch changes the example applications. I'm not sure I understand
> > why adding these arguments would force application to not use
> > rte_mempool_create() for packet buffers. Do you have a application in
> mind?
> >
> > For the mempool_ops parameter, we must pass it at init because we need
> > to know the mempool handler before populating the pool. For object
> > initialization, it can be done after, so I thought it was better to
> > reduce the number of arguments to avoid to fall in the
> > mempool_create() syndrom :)
> 
> I also agree with the proposal. Looks cleaner.
> 
> I would lean to the side of keeping the parameters to the minimum, i.e.
> not adding *obj_cb and *obj_cb_arg into rte_pktmbuf_pool_create.
> Developers always have the option of going with rte_mempool_create if they
> need more fine-grained control.

[Hemant] The implementations with hw offloaded mempools don't want developer 
using *rte_mempool_create* for packet buffer pools. 
This API does not work for hw offloaded mempool. 

Also, *rte_mempool_create_empty* - may not be convenient for many application, 
as it requires calling  4+ APIs.

Olivier is not in favor of deprecating the *rte_mempool_create*.   I agree with 
concerns raised by him. 

Essentially, I was suggesting to upgrade * rte_pktmbuf_pool_create* to be like 
*rte_mempool_create*  for packet buffers exclusively.

This will provide a clear segregation for API usages w.r.t the packet buffer 
pool vs all other type of mempools. 


Regards,
Hemant

> 
> Regards,
> Dave.
> 
> > Any other opinions?
> >
> > Regards,
> > Olivier

[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL

[Hemant Agrawal]

> -Original Message-
> From: Jan Viktorin [mailto:viktorin at rehivetech.com]

> On Sun, 18 Sep 2016 16:56:54 +0800
> Jianbo Liu  wrote:
> 
> > On 18 September 2016 at 15:22, Jan Viktorin 
> wrote:
> > > On Sun, 18 Sep 2016 13:58:50 +0800
> > > Jianbo Liu  wrote:
> > >
> > >> On 9 September 2016 at 16:43, Shreyansh Jain 
> wrote:
> > >> > Introduction:
> > >> > =
> > >> >
> > >> > This patch set is direct derivative of Jan's original series [1],[2].
> > >> >
> > >> >  - As this deviates substantially from original series, if need be I 
> > >> > can
> > >> >post it as a separate patch rather than v2. Please suggest.
> > >> >  - Also, there are comments on original v1 ([4]) which are _not_
> > >> >incorporated in this series as they refer to section no more in new
> > >> >version.
> > >> >  - This v3 version is based on the rte_driver/device patchset v9 [10].
> > >> >That series introduced device structures (rte_driver/rte_device)
> > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this
> > >> >patchset, XXX=>SOC.
> > >
> > > [...]
> > >
> > >> >
> > >> > 5) Design considerations that are different from PCI:
> > >> >  - Each driver implements its own scan and match function. PCI uses the
> BDF
> > >> >format to read the device from sysfs, but this _may_not_ be a case 
> > >> > for a
> > >> >SoC ethernet device.
> > >> >= This is an important change from initial proposal by Jan in [2]. 
> > >> > Unlike
> > >> >his attempt to use /sys/bus/platform, this patch relies on the
> > >> > PMD to
> > >>
> > >> It could be many redundant code if Each PMD driver has the scan
> > >> function if its own.
> > >> I think Jan's implementation is common to many platform drivers.
> > >
> > > I personally can find a use case for having a custom scan function.
> > > However, we should at least provide a default implementation.
> > > Probably, both the scan and match functions should be used to
> > > _override_ a default behaviour. So, only drivers that require to
> > > scan devices in a specific way would provide a custom function for this.
> > >
> > And for each platform/product
> >
> > > I agree, that this can sometimes lead to code duplication. Moreover,
> > > it opens door for a very non-standard, unsecure and wrong-by-design
> > > approaches. I'd like more to provide one or more scan
> > > implementations in EAL and do not put this responsibility on PMDs.

 [Hemant]  A common/default scan function can be added, provided at least one 
or more  PMD driver support it. 
w.r.t Jan's original scan function, it was not suitable for any of the NXP 
SoC's whether ARM or PowerPC.

Unable to validate the Jan's scan function on a real platform, we have skipped 
it for next phase.  
Addition of a default scan function can only be done in next phase, when we 
find a suitable SoC PMD driver supporting it.
> > >
> > >>
> > >> >detect the devices. This is because SoC may require specific or
> > >> >additional info for device detection. Further, SoC may have
> > >> > embedded
> > >
> > > Can you provide an example for "additional info for device detection"?
> > >
> > >>
> > >> Can you give us more precise definition about SoC driver? Does it
> > >> include the driver in ARM server?
> > >
> > > I am sorry but I don't understand this question.
> > >
> > > What you mean by a "driver in ARM server"? Do you mean a kernel driver?
> > >
> > > There is no "SoC driver" in the text so what definition are asking for?
> > >
> > This patchset introduces rte_soc_driver, which is inheriting from 
> > rte_driver.
> > I want to know what devices can use this SoC driver/device framework.
> > Is it for the devices from ARM servers, or embedded systems of
> > different vendors?
> 
> First, this is not an ARM-specific feature. Consider any MAC connected to the
> processor via some on-chip bus. In the world of ARM, it is usually a kind of
> AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example.
> Here they provide the Quick Path bus (but I don't know the details). So, you
> cannot access such device as PCI. It is usually not possible to distinguish 
> the bus
> type easily (Linux calls this a platform device).
> 
> So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-
> Chip). Such devices can have a lower access latency because they are closer to
> the processor.
> 
> So, if you have a server system driver by a SoC with integrated MACs (no PCI-E
> involved), there is no way how to access them from DPDK. An rte_soc_device
> represents such devices and provides a way how to access them from DPDK.
> That is the goal...
> 
> You can have an embedded device (router, switch, monitoring device, NAT,
> firewall, anything in a "small box" with high throughput demands) that 
> perfectly
> fits into this SoC framework because it would be usually based on some SoC
> (ARM, ARM64, ...).
> 
> > And this framework is too generalized, if we 

[dpdk-dev] [PATCH v3 2/2] mempool: pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

In the rte_pktmbuf_pool_create, if the default external mempool is
not available, the implementation can default to "ring_mp_mc", which
is an software implementation.

Signed-off-by: Hemant Agrawal 
---
Changes in V3:
* adding warning message to say that falling back to default sw pool
---
 lib/librte_mbuf/rte_mbuf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 4846b89..8ab0eb1 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -176,6 +176,14 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,

rte_errno = rte_mempool_set_ops_byname(mp,
RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
+
+   /* on error, try falling back to the software based default pool */
+   if (rte_errno == -EOPNOTSUPP) {
+   RTE_LOG(WARNING, MBUF, "Default HW Mempool not supported. "
+   "falling back to sw mempool \"ring_mp_mc\"");
+   rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
+   }
+
if (rte_errno != 0) {
RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
return NULL;
-- 
1.9.1

[dpdk-dev] [PATCH v3 1/2] eal/mempool: check for external mempool support

[Hemant Agrawal]

External offloaded mempool may not be available always. This check enables
run time verification of the presence of external mempool before the
mempool ops are installed.

An application built with a specific external mempool may work fine
on host. But, may not work on VM, specificaly if non-hw specific interfaces
are used e.g. virtio-net.

This is required to make sure that same application can work in all
environment for a given hw platform.

The solution proposed here is that rte_mempool_set_ops_byname should return
specific error in case the current execution environment is not supporting
the given mempool. Thereby allowing it to fallback on software mempool
implementation e.g. "ring_mp_mc"

This patch introduces new optional "supported" as mempool ops function
to check if external mempool instance is available or not.

Signed-off-by: Hemant Agrawal 
---
Changes in v2:
* fixed the pool_verify copy in rte_mempool_register_ops

Changes in v3:
* rename the pool_verify to supported as per David's review comment.
---
 lib/librte_mempool/rte_mempool.h   | 21 +
 lib/librte_mempool/rte_mempool_ops.c   | 19 +++
 lib/librte_mempool/rte_mempool_ring.c  |  4 
 lib/librte_mempool/rte_mempool_stack.c |  3 ++-
 4 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 0243f9e..322f177 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -387,6 +387,12 @@ typedef int (*rte_mempool_dequeue_t)(struct rte_mempool 
*mp,
  */
 typedef unsigned (*rte_mempool_get_count)(const struct rte_mempool *mp);

+/**
+ * Return if the given external mempool is supported for this instance.
+ * it is optional to implement for mempools
+ */
+typedef int (*rte_mempool_supported)(const struct rte_mempool *mp);
+
 /** Structure defining mempool operations structure */
 struct rte_mempool_ops {
char name[RTE_MEMPOOL_OPS_NAMESIZE]; /**< Name of mempool ops struct. */
@@ -395,6 +401,8 @@ struct rte_mempool_ops {
rte_mempool_enqueue_t enqueue;   /**< Enqueue an object. */
rte_mempool_dequeue_t dequeue;   /**< Dequeue an object. */
rte_mempool_get_count get_count; /**< Get qty of available objs. */
+   rte_mempool_supported supported;
+   /**< Verify if external mempool is supported for usages*/
 } __rte_cache_aligned;

 #define RTE_MEMPOOL_MAX_OPS_IDX 16  /**< Max registered ops structs */
@@ -516,6 +524,18 @@ void
 rte_mempool_ops_free(struct rte_mempool *mp);

 /**
+ * @internal wrapper to verify the external mempool availability
+ *
+ * @param mp
+ *   Pointer to the memory pool.
+ * @return
+ *   0: Success; external mempool instance is supported
+ * - <0: Error; external mempool instance is not supported
+ */
+int
+rte_mempool_ops_supported(const struct rte_mempool *mp);
+
+/**
  * Set the ops of a mempool.
  *
  * This can only be done on a mempool that is not populated, i.e. just after
@@ -531,6 +551,7 @@ rte_mempool_ops_free(struct rte_mempool *mp);
  *   - 0: Success; the mempool is now using the requested ops functions.
  *   - -EINVAL - Invalid ops struct name provided.
  *   - -EEXIST - mempool already has an ops struct assigned.
+ *   - -EOPNOTSUPP  - mempool instance not supported.
  */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
diff --git a/lib/librte_mempool/rte_mempool_ops.c 
b/lib/librte_mempool/rte_mempool_ops.c
index 5f24de2..4554062 100644
--- a/lib/librte_mempool/rte_mempool_ops.c
+++ b/lib/librte_mempool/rte_mempool_ops.c
@@ -85,6 +85,7 @@ rte_mempool_register_ops(const struct rte_mempool_ops *h)
ops->enqueue = h->enqueue;
ops->dequeue = h->dequeue;
ops->get_count = h->get_count;
+   ops->supported = h->supported;

rte_spinlock_unlock(_mempool_ops_table.sl);

@@ -123,6 +124,18 @@ rte_mempool_ops_get_count(const struct rte_mempool *mp)
return ops->get_count(mp);
 }

+/* wrapper to check if given external mempool is supported for this instance.*/
+int
+rte_mempool_ops_supported(const struct rte_mempool *mp)
+{
+   struct rte_mempool_ops *ops;
+
+   ops = rte_mempool_get_ops(mp->ops_index);
+   if (ops->supported)
+   return ops->supported(mp);
+   return 0;
+}
+
 /* sets mempool ops previously registered by rte_mempool_register_ops. */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
@@ -146,6 +159,12 @@ rte_mempool_set_ops_byname(struct rte_mempool *mp, const 
char *name,
if (ops == NULL)
return -EINVAL;

+   /*verify if the given mempool is supported for this instance */
+   if (ops->supported) {
+   if (ops->supported(mp))
+   return -EOPNOTSUPP;
+   }
+
mp->ops_index = i;
mp->pool_config = pool_config;
return 0;
diff --g

[dpdk-dev] [PATCH v2 2/2] mempool:pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

Hi David,

> -Original Message-
> From: Hunt, David [mailto:david.hunt at intel.com]
> Sent: Friday, September 16, 2016 2:00 PM
> To: Hemant Agrawal ; olivier.matz at 6wind.com
> Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com
> Subject: Re: [PATCH v2 2/2] mempool:pktmbuf pool default fallback for
> mempool ops error
> 
> Hi Hemant,
> 
> On 15/9/2016 6:13 PM, Hemant Agrawal wrote:
> > In the rte_pktmbuf_pool_create, if the default external mempool is not
> > available, the implementation can default to "ring_mp_mc", which is an
> > software implementation.
> >
> > Signed-off-by: Hemant Agrawal 
> > ---
> >   lib/librte_mbuf/rte_mbuf.c | 5 +
> >   1 file changed, 5 insertions(+)
> >
> > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> > index 4846b89..4adb4f5 100644
> > --- a/lib/librte_mbuf/rte_mbuf.c
> > +++ b/lib/librte_mbuf/rte_mbuf.c
> > @@ -176,6 +176,11 @@ rte_pktmbuf_pool_create(const char *name,
> > unsigned n,
> >
> > rte_errno = rte_mempool_set_ops_byname(mp,
> > RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
> > +
> > +   /* on error, try falling back to the software based default pool */
> > +   if (rte_errno == -EOPNOTSUPP)
> > +   rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc",
> NULL);
> 
> Should we log a warning message here saying that we're falling back to the
> mp/mc handler?
> 
[Hemant]Agree. Will add it. 

> > +
> > if (rte_errno != 0) {
> > RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
> > return NULL;

[dpdk-dev] [PATCH v2 1/2] eal/mempool: introduce check for external mempool availability

[Hemant Agrawal]

HI David,

> -Original Message-
> From: Hunt, David [mailto:david.hunt at intel.com]
> Sent: Friday, September 16, 2016 2:44 PM
> To: Hemant Agrawal ; olivier.matz at 6wind.com
> Cc: dev at dpdk.org; jerin.jacob at caviumnetworks.com
> Subject: Re: [PATCH v2 1/2] eal/mempool: introduce check for external
> mempool availability
> 
> Hi Hemant,
> 
> On 15/9/2016 6:13 PM, Hemant Agrawal wrote:
> > External offloaded mempool may not be available always. This check
> > enables run time verification of the presence of external mempool
> > before the mempool ops are installed.
> >
> > An application built with a specific external mempool may work fine on
> > host. But, may not work on VM, specificaly if non-hw specific
> > interfaces are used e.g. virtio-net.
> >
> > This is required to make sure that same application can work in all
> > environment for a given hw platform.
> >
> > The solution proposed here is that rte_mempool_set_ops_byname should
> > return specific error in case the current execution environment is not
> > supporting the given mempool. Thereby allowing it to fallback on
> > software mempool implementation e.g. "ring_mp_mc"
> >
> > This patch introduces new optional "pool_verify" as mempool ops
> > function to check if external mempool instance is available or not.
> 
> I've a small suggestion around the naming of the new functions. It seems to me
> that this patch is more about mempool handler 'support' than 'verification'.
> Could I suggest a different name for this new function? I think maybe
> "supported" may be more appropriate than "pool_verify". The return code that's
> returned when a mempool handler is not available is -EOPNOTSUPP, which is
> what suggested the word "supported" to me. I think that:
> 
>   if (ops->supported)
>   return ops->supported(mp);
> 
> makes for slightly easier reading. The wrapper function would logically then 
> be
> called  rte_mempool_ops_supported().

[Hemant] Good suggestion. I will update it in next version. 

> 
> 
> > Signed-off-by: Hemant Agrawal 
> > ---
> > Changes in v2:
> > * fixed the pool_verify copy in rte_mempool_register_ops
> > ---
> >   lib/librte_mempool/rte_mempool.h   | 21 +
> >   lib/librte_mempool/rte_mempool_ops.c   | 19 +++
> >   lib/librte_mempool/rte_mempool_ring.c  |  4 
> >   lib/librte_mempool/rte_mempool_stack.c |  3 ++-
> >   4 files changed, 46 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_mempool/rte_mempool.h
> b/lib/librte_mempool/rte_mempool.h
> > index 0243f9e..8599df1 100644
> > --- a/lib/librte_mempool/rte_mempool.h
> > +++ b/lib/librte_mempool/rte_mempool.h
> > @@ -387,6 +387,12 @@ typedef int (*rte_mempool_dequeue_t)(struct
> rte_mempool *mp,
> >*/
> >   typedef unsigned (*rte_mempool_get_count)(const struct rte_mempool
> *mp);
> >
> > +/**
> > + * Return if the given external mempool is available for this instance.
> > + * it is optional to implement for mempools
> > + */
> > +typedef int (*rte_mempool_pool_verify)(const struct rte_mempool *mp);
> > +
> >   /** Structure defining mempool operations structure */
> >   struct rte_mempool_ops {
> > char name[RTE_MEMPOOL_OPS_NAMESIZE]; /**< Name of mempool
> ops struct. */
> > @@ -395,6 +401,8 @@ struct rte_mempool_ops {
> > rte_mempool_enqueue_t enqueue;   /**< Enqueue an object. */
> > rte_mempool_dequeue_t dequeue;   /**< Dequeue an object. */
> > rte_mempool_get_count get_count; /**< Get qty of available objs. */
> > +   rte_mempool_pool_verify pool_verify;
> > +   /**< Verify if external mempool is available for usages*/
> >   } __rte_cache_aligned;
> >
> >   #define RTE_MEMPOOL_MAX_OPS_IDX 16  /**< Max registered ops structs
> */
> > @@ -516,6 +524,18 @@ void
> >   rte_mempool_ops_free(struct rte_mempool *mp);
> >
> >   /**
> > + * @internal wrapper to verify the external mempool availability
> > + *
> > + * @param mp
> > + *   Pointer to the memory pool.
> > + * @return
> > + *   0: Success; external mempool instance is available
> > + * - <0: Error; external mempool instance is not available
> > + */
> > +int
> > +rte_mempool_ops_pool_verify(const struct rte_mempool *mp);
> > +
> > +/**
> >* Set the ops of a mempool.
> >*
> >* This can only be done on a mempool that is not populated, i.e. just 
> > after
> > @@ -531,6 +551,7

[dpdk-dev] [PATCH v2 2/2] mempool:pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

In the rte_pktmbuf_pool_create, if the default external mempool is
not available, the implementation can default to "ring_mp_mc", which
is an software implementation.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_mbuf/rte_mbuf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 4846b89..4adb4f5 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -176,6 +176,11 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,

rte_errno = rte_mempool_set_ops_byname(mp,
RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
+
+   /* on error, try falling back to the software based default pool */
+   if (rte_errno == -EOPNOTSUPP)
+   rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
+
if (rte_errno != 0) {
RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
return NULL;
-- 
1.9.1

[dpdk-dev] [PATCH v2 1/2] eal/mempool: introduce check for external mempool availability

[Hemant Agrawal]

External offloaded mempool may not be available always. This check enables
run time verification of the presence of external mempool before the
mempool ops are installed.

An application built with a specific external mempool may work fine
on host. But, may not work on VM, specificaly if non-hw specific interfaces
are used e.g. virtio-net.

This is required to make sure that same application can work in all
environment for a given hw platform.

The solution proposed here is that rte_mempool_set_ops_byname should return
specific error in case the current execution environment is not supporting
the given mempool. Thereby allowing it to fallback on software mempool
implementation e.g. "ring_mp_mc"

This patch introduces new optional "pool_verify" as mempool ops function
to check if external mempool instance is available or not.

Signed-off-by: Hemant Agrawal 
---
Changes in v2:
* fixed the pool_verify copy in rte_mempool_register_ops
---
 lib/librte_mempool/rte_mempool.h   | 21 +
 lib/librte_mempool/rte_mempool_ops.c   | 19 +++
 lib/librte_mempool/rte_mempool_ring.c  |  4 
 lib/librte_mempool/rte_mempool_stack.c |  3 ++-
 4 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 0243f9e..8599df1 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -387,6 +387,12 @@ typedef int (*rte_mempool_dequeue_t)(struct rte_mempool 
*mp,
  */
 typedef unsigned (*rte_mempool_get_count)(const struct rte_mempool *mp);

+/**
+ * Return if the given external mempool is available for this instance.
+ * it is optional to implement for mempools
+ */
+typedef int (*rte_mempool_pool_verify)(const struct rte_mempool *mp);
+
 /** Structure defining mempool operations structure */
 struct rte_mempool_ops {
char name[RTE_MEMPOOL_OPS_NAMESIZE]; /**< Name of mempool ops struct. */
@@ -395,6 +401,8 @@ struct rte_mempool_ops {
rte_mempool_enqueue_t enqueue;   /**< Enqueue an object. */
rte_mempool_dequeue_t dequeue;   /**< Dequeue an object. */
rte_mempool_get_count get_count; /**< Get qty of available objs. */
+   rte_mempool_pool_verify pool_verify;
+   /**< Verify if external mempool is available for usages*/
 } __rte_cache_aligned;

 #define RTE_MEMPOOL_MAX_OPS_IDX 16  /**< Max registered ops structs */
@@ -516,6 +524,18 @@ void
 rte_mempool_ops_free(struct rte_mempool *mp);

 /**
+ * @internal wrapper to verify the external mempool availability
+ *
+ * @param mp
+ *   Pointer to the memory pool.
+ * @return
+ *   0: Success; external mempool instance is available
+ * - <0: Error; external mempool instance is not available
+ */
+int
+rte_mempool_ops_pool_verify(const struct rte_mempool *mp);
+
+/**
  * Set the ops of a mempool.
  *
  * This can only be done on a mempool that is not populated, i.e. just after
@@ -531,6 +551,7 @@ rte_mempool_ops_free(struct rte_mempool *mp);
  *   - 0: Success; the mempool is now using the requested ops functions.
  *   - -EINVAL - Invalid ops struct name provided.
  *   - -EEXIST - mempool already has an ops struct assigned.
+ *   - -EOPNOTSUPP  - mempool instance not available.
  */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
diff --git a/lib/librte_mempool/rte_mempool_ops.c 
b/lib/librte_mempool/rte_mempool_ops.c
index 5f24de2..c2e765f 100644
--- a/lib/librte_mempool/rte_mempool_ops.c
+++ b/lib/librte_mempool/rte_mempool_ops.c
@@ -85,6 +85,7 @@ rte_mempool_register_ops(const struct rte_mempool_ops *h)
ops->enqueue = h->enqueue;
ops->dequeue = h->dequeue;
ops->get_count = h->get_count;
+   ops->pool_verify = h->pool_verify;

rte_spinlock_unlock(_mempool_ops_table.sl);

@@ -123,6 +124,18 @@ rte_mempool_ops_get_count(const struct rte_mempool *mp)
return ops->get_count(mp);
 }

+/* wrapper to check if given external mempool is available for this instance.*/
+int
+rte_mempool_ops_pool_verify(const struct rte_mempool *mp)
+{
+   struct rte_mempool_ops *ops;
+
+   ops = rte_mempool_get_ops(mp->ops_index);
+   if (ops->pool_verify)
+   return ops->pool_verify(mp);
+   return 0;
+}
+
 /* sets mempool ops previously registered by rte_mempool_register_ops. */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
@@ -146,6 +159,12 @@ rte_mempool_set_ops_byname(struct rte_mempool *mp, const 
char *name,
if (ops == NULL)
return -EINVAL;

+   /*verify if the given mempool is available for this instance */
+   if (ops->pool_verify) {
+   if (ops->pool_verify(mp))
+   return -EOPNOTSUPP;
+   }
+
mp->ops_index = i;
mp->pool_config = pool_config;
return 0;
diff --git a/lib/librte_mempool/rte_mempool_ring.c 
b/lib

[dpdk-dev] [PATCH 2/2] mempool:pktmbuf pool default fallback for mempool ops error

[Hemant Agrawal]

In the rte_pktmbuf_pool_create, if the default external mempool is
not available, the implementation can default to "ring_mp_mc", which
is an software implementation.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_mbuf/rte_mbuf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 4846b89..4adb4f5 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -176,6 +176,11 @@ rte_pktmbuf_pool_create(const char *name, unsigned n,

rte_errno = rte_mempool_set_ops_byname(mp,
RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
+
+   /* on error, try falling back to the software based default pool */
+   if (rte_errno == -EOPNOTSUPP)
+   rte_errno = rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL);
+
if (rte_errno != 0) {
RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
return NULL;
-- 
1.9.1

[dpdk-dev] [PATCH 1/2] eal/mempool: introduce check for external mempool availability

[Hemant Agrawal]

External offloaded mempool may not be available always. This check enables
run time verification of the presence of external mempool before the
mempool ops are installed. 

An application built with a specific external mempool may work fine
on host. But, may not work on VM, specificaly if non-hw specific interfaces
are used e.g. virtio-net.

This is required to make sure that same application can work in all
environment for a given hw platform.

The solution proposed here is that rte_mempool_set_ops_byname should return
specific error in case the current execution environment is not supporting
the given mempool. Thereby allowing it to fallback on software mempool
implementation e.g. "ring_mp_mc"

This patch introduces new optional "pool_verify" as mempool ops function
to check if external mempool instance is available or not.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_mempool/rte_mempool.h   | 21 +
 lib/librte_mempool/rte_mempool_ops.c   | 18 ++
 lib/librte_mempool/rte_mempool_ring.c  |  4 
 lib/librte_mempool/rte_mempool_stack.c |  3 ++-
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 059ad9e..67e12d1 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -385,6 +385,12 @@ typedef int (*rte_mempool_dequeue_t)(struct rte_mempool 
*mp,
  */
 typedef unsigned (*rte_mempool_get_count)(const struct rte_mempool *mp);

+/**
+ * Return if the given external mempool is available for this instance.
+ * it is optional to implement for mempools
+ */
+typedef int (*rte_mempool_pool_verify)(const struct rte_mempool *mp);
+
 /** Structure defining mempool operations structure */
 struct rte_mempool_ops {
char name[RTE_MEMPOOL_OPS_NAMESIZE]; /**< Name of mempool ops struct. */
@@ -393,6 +399,8 @@ struct rte_mempool_ops {
rte_mempool_enqueue_t enqueue;   /**< Enqueue an object. */
rte_mempool_dequeue_t dequeue;   /**< Dequeue an object. */
rte_mempool_get_count get_count; /**< Get qty of available objs. */
+   rte_mempool_pool_verify pool_verify;
+   /**< Verify if external mempool is available for usages*/
 } __rte_cache_aligned;

 #define RTE_MEMPOOL_MAX_OPS_IDX 16  /**< Max registered ops structs */
@@ -514,6 +522,18 @@ void
 rte_mempool_ops_free(struct rte_mempool *mp);

 /**
+ * @internal wrapper to verify the external mempool availability
+ *
+ * @param mp
+ *   Pointer to the memory pool.
+ * @return
+ *   0: Success; external mempool instance is available
+ * - <0: Error; external mempool instance is not available
+ */
+int
+rte_mempool_ops_pool_verify(const struct rte_mempool *mp);
+
+/**
  * Set the ops of a mempool.
  *
  * This can only be done on a mempool that is not populated, i.e. just after
@@ -529,6 +549,7 @@ rte_mempool_ops_free(struct rte_mempool *mp);
  *   - 0: Success; the mempool is now using the requested ops functions.
  *   - -EINVAL - Invalid ops struct name provided.
  *   - -EEXIST - mempool already has an ops struct assigned.
+ *   - -EOPNOTSUPP  - mempool instance not available.
  */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
diff --git a/lib/librte_mempool/rte_mempool_ops.c 
b/lib/librte_mempool/rte_mempool_ops.c
index 5f24de2..4119882 100644
--- a/lib/librte_mempool/rte_mempool_ops.c
+++ b/lib/librte_mempool/rte_mempool_ops.c
@@ -123,6 +123,18 @@ rte_mempool_ops_get_count(const struct rte_mempool *mp)
return ops->get_count(mp);
 }

+/* wrapper to check if given external mempool is available for this instance.*/
+int
+rte_mempool_ops_pool_verify(const struct rte_mempool *mp)
+{
+   struct rte_mempool_ops *ops;
+
+   ops = rte_mempool_get_ops(mp->ops_index);
+   if (ops->pool_verify)
+   return ops->pool_verify(mp);
+   return 0;
+}
+
 /* sets mempool ops previously registered by rte_mempool_register_ops. */
 int
 rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name,
@@ -146,6 +158,12 @@ rte_mempool_set_ops_byname(struct rte_mempool *mp, const 
char *name,
if (ops == NULL)
return -EINVAL;

+   /*verify if the given mempool is available for this instance */
+   if (ops->pool_verify) {
+   if (ops->pool_verify(mp))
+   return -EOPNOTSUPP;
+   }
+
mp->ops_index = i;
mp->pool_config = pool_config;
return 0;
diff --git a/lib/librte_mempool/rte_mempool_ring.c 
b/lib/librte_mempool/rte_mempool_ring.c
index b9aa64d..d86d5e0 100644
--- a/lib/librte_mempool/rte_mempool_ring.c
+++ b/lib/librte_mempool/rte_mempool_ring.c
@@ -126,6 +126,7 @@ static const struct rte_mempool_ops ops_mp_mc = {
.enqueue = common_ring_mp_enqueue,
.dequeue = common_ring_mc_dequeue,
.get_count = common_ring_get_count,
+   .pool_verify = NULL,
 };

 s

[dpdk-dev] [PATCH] examples/l3fwd: enabling 4m hash for all 64 bit archs

[Hemant Agrawal]

This patch enables the support for 4 million hash entries
for all 64 bit architectures.

Signed-off-by: Hemant Agrawal 
---
 examples/l3fwd/l3fwd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index d8798b7..011ba14 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -68,7 +68,7 @@
 #defineMASK_ETH 0x3f

 /* Hash parameters. */
-#ifdef RTE_ARCH_X86_64
+#ifdef RTE_ARCH_64
 /* default to 4 million hash entries (approx) */
 #define L3FWD_HASH_ENTRIES (1024*1024*4)
 #else
-- 
1.9.1

[dpdk-dev] [PATCH] examples/l3fwd: em path hash offload to machine

[Hemant Agrawal]

if machine level CRC extension are available, offload the
hash to machine provided functions e.g. armv8-a CRC extensions
support it

Signed-off-by: Hemant Agrawal 
---
 examples/l3fwd/l3fwd_em.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index def5a02..a889c67 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -58,13 +58,13 @@

 #include "l3fwd.h"

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
 #include 
 #define DEFAULT_HASH_FUNC   rte_hash_crc
 #else
 #include 
 #define DEFAULT_HASH_FUNC   rte_jhash
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

 #define IPV6_ADDR_LEN 16

@@ -169,17 +169,17 @@ ipv4_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
init_val = rte_hash_crc_4byte(t, init_val);
init_val = rte_hash_crc_4byte(k->ip_src, init_val);
init_val = rte_hash_crc_4byte(k->ip_dst, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash_1word(k->ip_src, init_val);
init_val = rte_jhash_1word(k->ip_dst, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

return init_val;
 }
@@ -191,16 +191,16 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
const union ipv6_5tuple_host *k;
uint32_t t;
const uint32_t *p;
-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
const uint32_t  *ip_src0, *ip_src1, *ip_src2, *ip_src3;
const uint32_t  *ip_dst0, *ip_dst1, *ip_dst2, *ip_dst3;
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif

k = data;
t = k->proto;
p = (const uint32_t *)>port_src;

-#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
+#if defined(RTE_MACHINE_CPUFLAG_SSE4_2) || defined(RTE_MACHINE_CPUFLAG_CRC32)
ip_src0 = (const uint32_t *) k->ip_src;
ip_src1 = (const uint32_t *)(k->ip_src+4);
ip_src2 = (const uint32_t *)(k->ip_src+8);
@@ -219,14 +219,14 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t 
data_len,
init_val = rte_hash_crc_4byte(*ip_dst2, init_val);
init_val = rte_hash_crc_4byte(*ip_dst3, init_val);
init_val = rte_hash_crc_4byte(*p, init_val);
-#else /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#else
init_val = rte_jhash_1word(t, init_val);
init_val = rte_jhash(k->ip_src,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash(k->ip_dst,
sizeof(uint8_t) * IPV6_ADDR_LEN, init_val);
init_val = rte_jhash_1word(*p, init_val);
-#endif /* RTE_MACHINE_CPUFLAG_SSE4_2 */
+#endif
return init_val;
 }

-- 
1.9.1

[dpdk-dev] [PATCH] eal/armv8: high-resolution cycle counter

[Hemant Agrawal]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob
> Sent: Thursday, August 18, 2016 5:22 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; jianbo.liu at linaro.org;
> viktorin at rehivetech.com; Jerin Jacob 
> Subject: [dpdk-dev] [PATCH] eal/armv8: high-resolution cycle counter
> 
> Existing cntvct_el0 based rte_rdtsc() provides portable means to get wall 
> clock
> counter at user space. Typically it runs at <= 100MHz.
> 
> The alternative method to enable rte_rdtsc() for high resolution wall clock
> counter is through armv8 PMU subsystem.
> The PMU cycle counter runs at CPU frequency, However, access to PMU cycle
> counter from user space is not enabled by default in the arm64 linux kernel.
> It is possible to enable cycle counter at user space access by configuring the
> PMU from the privileged mode (kernel space).
> 
> by default rte_rdtsc() implementation uses portable
> cntvct_el0 scheme. Application can choose the PMU based implementation with
> CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
> 
> Signed-off-by: Jerin Jacob 

Acked-by: Hemant Agrawal 

[dpdk-dev] usages issue with external mempool

[Hemant Agrawal]

Hi Oliver

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Thursday, July 28, 2016 2:03 PM
> On 07/27/2016 11:51 AM, Jerin Jacob wrote:
> > On Tue, Jul 26, 2016 at 10:11:13AM +0000, Hemant Agrawal wrote:
> >> Hi,
> >> There was lengthy discussions w.r.t external mempool 
> >> patches.
> However, I am still finding usages issue with the agreed approach.
> >>
> >> The existing API to create packet mempool, "rte_pktmbuf_pool_create" does
> not provide the option to change the object init iterator. This may be the 
> reason
> that many applications (e.g. OVS) are using rte_mempool_create to create
> packet mempool  with their own object iterator (e.g. ovs_rte_pktmbuf_init).
> >>
> >> e.g the existing usages are:
> >>  dmp->mp = rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu),
> >>   MP_CACHE_SZ,
> >>   sizeof(struct 
> >> rte_pktmbuf_pool_private),
> >>   rte_pktmbuf_pool_init, NULL,
> >>   ovs_rte_pktmbuf_init, NULL,
> >>  socket_id, 0);
> >>
> >>
> >> With the new API set for packet pool create, this need to be changed to:
> >>
> >>  dmp->mp = rte_mempool_create_empty(mp_name, mp_size,
> MBUF_SIZE(mtu),
> >>   MP_CACHE_SZ,
> >>   sizeof(struct 
> >> rte_pktmbuf_pool_private),
> >>   socket_id, 0);
> >>if (dmp->mp == NULL)
> >>   break;
> >>
> >>rte_errno = 
> >> rte_mempool_set_ops_byname(dmp-mp,
> >>  
> >> RTE_MBUF_DEFAULT_MEMPOOL_OPS,
> NULL);
> >>if (rte_errno != 0) {
> >>   RTE_LOG(ERR, MBUF, "error 
> >> setting mempool
> handler\n");
> >>   return NULL;
> >>}
> >>rte_pktmbuf_pool_init(dmp->mp, NULL);
> >>
> >>ret = rte_mempool_populate_default(dmp->mp);
> >>if (ret < 0) {
> >>   rte_mempool_free(dmp->mp);
> >>   rte_errno = -ret;
> >>   return NULL;
> >>}
> >>
> >>rte_mempool_obj_iter(dmp->mp,
> >> ovs_rte_pktmbuf_init, NULL);
> >>
> >> This is not a user friendly approach to ask for changing 1 API to 6 new 
> >> APIs.
> Or, am I missing something?
> 
> The example you are giving first still works today, right?

[Hemant] No. The rte_mempool_create, may not work with offloaded mempool.  In 
the current code, the default option in rte_mempool_create is hardcoded as 
"ring_mp_mc". So it will not use any other config file specified mempool. One 
possible solution, I see that the default option in rte_mempool_create can be 
changed to  "CONFIG_RTE_MBUF_DEFAULT_MEMPOOL_OPS"  from "ring_mp_mc".

> 
> Since the mempool rework, as the objects are linked together in the mempool, 
> it
> is also possible to use rte_pktmbuf_pool_create() and call another iterator 
> after,
> like below:
> 
>   mp = rte_pktmbuf_pool_create(name, size, cache_size, priv_size,
>   data_room_size, socket_id);
>   if (mp == NULL)
>   handle_error();
>   rte_mempool_obj_iter(mp, ovs_rte_pktmbuf_init);
> 
[Hemant] Why? The purpose of rte_pktmbuf_pool_create was to provide a usable 
wrapper. If applications are not able to use it, we should retrospect and 
upgrade it as per common usages. your ease-of-usages definition may differ from 
my definition. 

> By the way, rte_mempool_set_ops_byname() is not needed in your example
> above since it sets the default ops.

[Hemant] I think it is needed. I could not find a MEMPOOL_REGISTER_OPS for 
"default" value. Default may not be ""ring_mp_mc".

> 
> >
> > I agree, To me, this is very bad. I have raised this concern earlier
> > also
> >
> >

[dpdk-dev] usages issue with external mempool

[Hemant Agrawal]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, July 27, 2016 7:05 PM
> To: Hemant Agrawal 
> Cc: Jerin Jacob ; David Hunt
> ; dev at dpdk.org; olivier.matz at 6wind.com;
> viktorin at rehivetech.com; Shreyansh Jain 
> Subject: Re: usages issue with external mempool
> 
> 2016-07-27 13:23, Hemant Agrawal:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2016-07-27 15:21, Jerin Jacob:
> > > > If we agree on this then may be I can send the API deprecation
> > > > notices for rte_mempool_create for v16.11
> > >
> > > It would have been a lot better to send a patch during the 16.07
> > > cycle to avoid breaking again the API.
> > > I'm afraid it will even be too late for the deprecation notice.
> >
> > [Hemant] Yes! It is late.
> >  we can make these changes immediately after 16.07.
> 
> You cannot change the API in 16.11 without having a deprecation agreement in
> 16.07.
[Hemant] Can you still accommodate the deprecation notice for 16.07? 

[dpdk-dev] usages issue with external mempool

[Hemant Agrawal]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> 2016-07-27 15:21, Jerin Jacob:
> > On Tue, Jul 26, 2016 at 10:11:13AM +, Hemant Agrawal wrote:
> > > This is not a user friendly approach to ask for changing 1 API to 6 new 
> > > APIs.
> Or, am I missing something?
> >
> > I agree, To me, this is very bad. I have raised this concern earlier
> > also
> >
> > Since applications like OVS goes through "rte_mempool_create" for even
> > packet buffer pool creation. IMO it make senses to extend
> > "rte_mempool_create" to take one more argument to provide external
> > pool handler name(NULL for default). I don't see any valid technical
> > reason to treat external pool handler based mempool creation API
> > different from default handler.

[Hemant] It is better. 
However, I will also suggest to upgrade "rte_pktmbuf_pool_create" with 
obj_init, this will create consistency in applications to use it instead of 
using rte_mempool_create.

> >
> > Oliver, David
> >
> > Thoughts ?
> >
> > If we agree on this then may be I can send the API deprecation notices
> > for rte_mempool_create for v16.11
> 
> It would have been a lot better to send a patch during the 16.07 cycle to 
> avoid
> breaking again the API.
> I'm afraid it will even be too late for the deprecation notice.

[Hemant] Yes! It is late. 
 we can make these changes immediately after 16.07.

[dpdk-dev] usages issue with external mempool

[Hemant Agrawal]

Hi,
   There was lengthy discussions w.r.t external mempool patches. 
However, I am still finding usages issue with the agreed approach.

The existing API to create packet mempool, "rte_pktmbuf_pool_create" does not 
provide the option to change the object init iterator. This may be the reason 
that many applications (e.g. OVS) are using rte_mempool_create to create packet 
mempool  with their own object iterator (e.g. ovs_rte_pktmbuf_init).

e.g the existing usages are:
dmp->mp = rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu),
 MP_CACHE_SZ,
 sizeof(struct rte_pktmbuf_pool_private),
 rte_pktmbuf_pool_init, NULL,
 ovs_rte_pktmbuf_init, NULL,
socket_id, 0);


With the new API set for packet pool create, this need to be changed to:

dmp->mp = rte_mempool_create_empty(mp_name, mp_size, MBUF_SIZE(mtu),
 MP_CACHE_SZ,
 sizeof(struct rte_pktmbuf_pool_private),
 socket_id, 0);
  if (dmp->mp == NULL)
 break;

  rte_errno = rte_mempool_set_ops_byname(dmp-mp,

RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
  if (rte_errno != 0) {
 RTE_LOG(ERR, MBUF, "error setting 
mempool handler\n");
 return NULL;
  }
  rte_pktmbuf_pool_init(dmp->mp, NULL);

  ret = rte_mempool_populate_default(dmp->mp);
  if (ret < 0) {
 rte_mempool_free(dmp->mp);
 rte_errno = -ret;
 return NULL;
  }

  rte_mempool_obj_iter(dmp->mp, 
ovs_rte_pktmbuf_init, NULL);

This is not a user friendly approach to ask for changing 1 API to 6 new APIs. 
Or, am I missing something?

I think, we should do one of the following:

1. Enhance "rte_pktmbuf_pool_create" to optionally accept "rte_mempool_obj_cb_t 
*obj_init, void *obj_init_arg" as inputs. If obj_init is not present, default 
can be used.
2. Create a new wrapper API (e.g. e_pktmbuf_pool_create_new) with  the above 
said behavior e.g.:
/* helper to create a mbuf pool */
struct rte_mempool *
rte_pktmbuf_pool_create_new(const char *name, unsigned n,
   unsigned cache_size, uint16_t priv_size, uint16_t data_room_size,
rte_mempool_obj_cb_t *obj_init, void *obj_init_arg,
   int socket_id)
3. Let the existing rte_mempool_create accept flag as "MEMPOOL_F_HW_PKT_POOL". 
Obviously, if this flag is set - all other flag values should be ignored. This 
was discussed earlier also.

Please share your opinion.

Regards,
Hemant

[dpdk-dev] [PATCH 2/2] example/ipsec-secgw: add support for cryptodev_start

[Hemant Agrawal]

The usual device sequence is configure, queue setup and start.
Crypto device should be started before use.

Signed-off-by: Akhil Goyal 
Signed-off-by: Hemant Agrawal 
---
 examples/ipsec-secgw/ipsec-secgw.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/examples/ipsec-secgw/ipsec-secgw.c 
b/examples/ipsec-secgw/ipsec-secgw.c
index 1ca144b..302499c 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1273,6 +1273,10 @@ cryptodevs_init(void)
_conf, dev_conf.socket_id))
rte_panic("Failed to setup queue %u for "
"cdev_id %u\n", 0, cdev_id);
+   /* Start device */
+   if (rte_cryptodev_start(cdev_id))
+   rte_panic("Failed to start crypto dev for "
+   "cdev_id=%u\n", cdev_id);
}

printf("\n");
-- 
1.9.1

[dpdk-dev] [PATCH 1/2] example/l2fwd-crypto: add support for cryptodev_start

[Hemant Agrawal]

The usual device sequence is configure, queue setup and start.
Crypto device should be started before use.

Signed-off-by: Akhil Goyal 
Signed-off-by: Hemant Agrawal 
---
 examples/l2fwd-crypto/main.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index dd39cc1..62e1c39 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1793,6 +1793,12 @@ initialize_cryptodevs(struct l2fwd_crypto_options 
*options, unsigned nb_ports,
if (retval < 0) {
printf("Failed to setup queue pair %u on cryptodev %u",
0, cdev_id);
+   }
+   /* Start device */
+   retval = rte_cryptodev_start(cdev_id);
+   if (retval < 0) {
+   printf("rte_cryptodev_start:err=%d, cdev_id=%u\n",
+  retval, (unsigned)cdev_id);
return -1;
}

-- 
1.9.1

[dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio

[Hemant Agrawal]

> -Original Message-
> From: Jianbo Liu [mailto:jianbo.liu at linaro.org]
> Sent: Friday, May 13, 2016 7:13 AM
> To: Santosh Shukla 
> Cc: Stephen Hemminger ; Jerin Jacob
> ; Hemant Agrawal
> ; dev at dpdk.org; Thomas Monjalon
> 
> Subject: Re: [dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio
> 
> On 12 May 2016 at 18:31, Santosh Shukla
>  wrote:
> > On Thu, May 12, 2016 at 05:52:54PM +0800, Jianbo Liu wrote:
> >> On 12 May 2016 at 16:57, Santosh Shukla
> >>  wrote:
> >> > On Thu, May 12, 2016 at 01:54:13PM +0800, Jianbo Liu wrote:
> >> >> On 12 May 2016 at 13:06, Santosh Shukla
> >> >>  wrote:
> >> >> > On Thu, May 12, 2016 at 11:42:26AM +0800, Jianbo Liu wrote:
> >> >> >> On 12 May 2016 at 11:17, Santosh Shukla
> >> >> >>  wrote:
> >> >> >> > On Thu, May 12, 2016 at 10:01:05AM +0800, Jianbo Liu wrote:
> >> >> >> >> On 12 May 2016 at 02:25, Stephen Hemminger
>  wrote:
> >> >> >> >> > On Wed, 11 May 2016 22:32:16 +0530 Jerin Jacob
> >> >> >> >> >  wrote:
> >> >> >> >> >
> >> >> >> >> >> On Wed, May 11, 2016 at 08:22:59AM -0700, Stephen
> Hemminger wrote:
> >> >> >> >> >> > On Wed, 11 May 2016 19:17:58 +0530 Hemant Agrawal
> >> >> >> >> >> >  wrote:
> >> >> >> >> >> >
> >> >> >> >> >> > > IGB_UIO not supported for arm64 arch in kernel so disable.
> >> >> >> >> >> > >
> >> >> >> >> >> > > Signed-off-by: Hemant Agrawal
> >> >> >> >> >> > > 
> >> >> >> >> >> > > Reviewed-by: Santosh Shukla
> >> >> >> >> >> > > 
> >> >> >> >> >> >
> >> >> >> >> >> > Really, I have use IGB_UIO on ARM64
> >> >> >> >> >>
> >> >> >> >> >> May I know what is the technical use case for igb_uio on
> >> >> >> >> >> arm64 which cannot be addressed through vfio or vfioionommu.
> >> >> >> >> >
> >> >> >> >> > I was running on older kernel which did not support vfioionommu
> mode.
> >> >> >> >>
> >> >> >> >> As I said, most of DPDK developers are not kernel
> >> >> >> >> developers. They may have their own kernel tree, and
> >> >> >> >> couldn't like to upgrade to latest kernel.
> >> >> >> >> They can choose to use or not use igb_uio when binding the
> >> >> >> >> driver. But blindly disabling it in the base config seems 
> >> >> >> >> unreasonable.
> >> >> >> >
> >> >> >> > if user keeping his own kernel so they could also keep
> >> >> >> > IGB_UIO=y in their local
> >> >> >> Most likely they don't have local dpdk tree. They write their
> >> >> >> own applications, complie and link to dpdk lib, then done.
> >> >> >>
> >> >> >> > dpdk tree. Why are you imposing user-x custome depedancy on
> >> >> >> > upstream dpdk base
> >> >> >> Customer requiremnts is important. I want they can choose the way
> they like.
> >> >> >>
> >> >> >
> >> >> > so you choose to keep igb_uio option, provided arch doesn't support?
> >> >> > new user did reported issues with igb_uio for arm64, refer this
> >> >> > thread [1], as well hemanth too faced issues. we want to avoid that.
> >> >> >
> >> >> > If customer maintaing out-of-tree kernel then he can also switch to 
> >> >> > vfio-
> way.
> >> >> > isn;t it?
> >> >> >
> >> >> >> > config. Is it not enough for explanation that - Base config
> >> >> >> > ie.. armv8 doesn;t support pci mmap, so igb_uio is n/a. New
> >> >> >> > user wont able to build/run dpdk/arm64 in igb_uio-way, He'll
> >> >> >> > prefer to use upstream stuff. I think, you are not making
> >> >> >> You are wrong, he can build dpdk. If he like 

[dpdk-dev] [PATCHv3 2/2] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

This patch introduces dpaa2 machine target to address difference
in cpu parameter, number of core to 8 and no numa support
w.r.t default armv8-a machine

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 42 ++
 mk/machine/dpaa2/rte.vars.mk  | 60 +++
 2 files changed, 102 insertions(+)
 create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
 create mode 100644 mk/machine/dpaa2/rte.vars.mk

diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
new file mode 100644
index 000..66df54c
--- /dev/null
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -0,0 +1,42 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "defconfig_arm64-armv8a-linuxapp-gcc"
+
+# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
+CONFIG_RTE_MACHINE="dpaa2"
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
+
+#
+# Compile Environment Abstraction Layer
+#
+CONFIG_RTE_MAX_LCORE=8
+CONFIG_RTE_MAX_NUMA_NODES=1
diff --git a/mk/machine/dpaa2/rte.vars.mk b/mk/machine/dpaa2/rte.vars.mk
new file mode 100644
index 000..8541633
--- /dev/null
+++ b/mk/machine/dpaa2/rte.vars.mk
@@ -0,0 +1,60 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+#   - can define ARCH variable (overridden by cmdline value)
+#   - can define CROSS variable (overridden by cmdline value)
+#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+#   - can define CPU_CFLAGS variable (overridden by cm

[dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio

[Hemant Agrawal]

IGB_UIO not supported for arm64 arch in kernel so disable.

Signed-off-by: Hemant Agrawal 
Reviewed-by: Santosh Shukla 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 9abeca4..a786562 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -42,6 +42,8 @@ CONFIG_RTE_FORCE_INTRINSICS=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

+CONFIG_RTE_EAL_IGB_UIO=n
+
 CONFIG_RTE_IXGBE_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
-- 
1.9.1

[dpdk-dev] [PATCHv2 2/2] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

This patch introduces dpaa2 machine target to address difference
in cpu parameter, number of core to 8 and no numa support
w.r.t default armv8-a machine

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 42 ++
 mk/machine/dpaa2/rte.vars.mk  | 60 +++
 2 files changed, 102 insertions(+)
 create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
 create mode 100644 mk/machine/dpaa2/rte.vars.mk

diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
new file mode 100644
index 000..66df54c
--- /dev/null
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -0,0 +1,42 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "defconfig_arm64-armv8a-linuxapp-gcc"
+
+# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
+CONFIG_RTE_MACHINE="dpaa2"
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
+
+#
+# Compile Environment Abstraction Layer
+#
+CONFIG_RTE_MAX_LCORE=8
+CONFIG_RTE_MAX_NUMA_NODES=1
diff --git a/mk/machine/dpaa2/rte.vars.mk b/mk/machine/dpaa2/rte.vars.mk
new file mode 100644
index 000..8541633
--- /dev/null
+++ b/mk/machine/dpaa2/rte.vars.mk
@@ -0,0 +1,60 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+#   - can define ARCH variable (overridden by cmdline value)
+#   - can define CROSS variable (overridden by cmdline value)
+#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
+#   - can define CPU_CFLAGS variable (overridden by cm

[dpdk-dev] [PATCHv2 1/2] mk:disabling CONFIG_RTE_EAL_IGB_UIO for armv8a

[Hemant Agrawal]

The compilation with upstream kernel is broken with this config as enabled.

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-armv8a-linuxapp-gcc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 9abeca4..a786562 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -42,6 +42,8 @@ CONFIG_RTE_FORCE_INTRINSICS=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

+CONFIG_RTE_EAL_IGB_UIO=n
+
 CONFIG_RTE_IXGBE_INC_VECTOR=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
-- 
1.9.1

[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

This patch introduces dpaa2 machine target to address difference
in cpu parameter, number of core to 8 and no numa support
w.r.t default armv8-a machine

Signed-off-by: Hemant Agrawal 
---
 config/defconfig_arm64-dpaa2-linuxapp-gcc | 44 +++
 mk/machine/dpaa2/rte.vars.mk  | 60 +++
 mk/rte.module.mk  |  5 +++
 3 files changed, 109 insertions(+)
 create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
 create mode 100644 mk/machine/dpaa2/rte.vars.mk

diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
b/config/defconfig_arm64-dpaa2-linuxapp-gcc
new file mode 100644
index 000..80bda26
--- /dev/null
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -0,0 +1,44 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "defconfig_arm64-armv8a-linuxapp-gcc"
+
+# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
+CONFIG_RTE_MACHINE="dpaa2"
+CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
+
+#
+# Compile Environment Abstraction Layer
+#
+CONFIG_RTE_MAX_LCORE=8
+CONFIG_RTE_MAX_NUMA_NODES=1
+CONFIG_RTE_EAL_IGB_UIO=n
+CONFIG_RTE_EAL_VFIO=y
diff --git a/mk/machine/dpaa2/rte.vars.mk b/mk/machine/dpaa2/rte.vars.mk
new file mode 100644
index 000..8541633
--- /dev/null
+++ b/mk/machine/dpaa2/rte.vars.mk
@@ -0,0 +1,60 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Freescale Semiconductor nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+#
+# machine:
+#
+#   - can define ARCH variable (overridden by cmdline value)
+#   - can define CROSS variable (overridden by cmdline value)
+#   - define MACHINE_CFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
+#   - define MACHINE_ASFLAGS

[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

From: Santosh Shukla [mailto:sshu...@mvista.com]
Sent: Monday, May 09, 2016 2:44 PM
To: Jerin Jacob 
Cc: Hemant Agrawal ; dpdk ; Jianbo 
Liu ; Shukla, Santosh 
Subject: Re: [dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on 
armv8-a



On Mon, May 9, 2016 at 2:36 PM, Jerin Jacob mailto:jerin.jacob at caviumnetworks.com>> wrote:
On Mon, May 09, 2016 at 07:18:22PM +0530, Hemant Agrawal wrote:
> This patch introduces dpaa2 machine target to address difference
> in cpu parameter, number of core to 8 and no numa support
> w.r.t default armv8-a machine
>
> Signed-off-by: Hemant Agrawal  nxp.com<mailto:hemant.agrawal at nxp.com>>
> ---
>  config/defconfig_arm64-dpaa2-linuxapp-gcc | 44 +++
>  mk/machine/dpaa2/rte.vars.mk<http://rte.vars.mk>  | 60 
> +++
>  mk/rte.module.mk<http://rte.module.mk>  |  5 +++
>  3 files changed, 109 insertions(+)
>  create mode 100644 config/defconfig_arm64-dpaa2-linuxapp-gcc
>  create mode 100644 mk/machine/dpaa2/rte.vars.mk<http://rte.vars.mk>
>
> diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc 
> b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> new file mode 100644
> index 000..80bda26
> --- /dev/null
> +++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
> @@ -0,0 +1,44 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#   the documentation and/or other materials provided with the
> +#   distribution.
> +# * Neither the name of Freescale Semiconductor nor the names of its
> +#   contributors may be used to endorse or promote products derived
> +#   from this software without specific prior written permission.
> +#
> +#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +#include "defconfig_arm64-armv8a-linuxapp-gcc"
> +
> +# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
> +CONFIG_RTE_MACHINE="dpaa2"
> +CONFIG_RTE_ARCH_ARM_TUNE="cortex-a57+fp+simd"
> +
> +#
> +# Compile Environment Abstraction Layer
> +#
> +CONFIG_RTE_MAX_LCORE=8
> +CONFIG_RTE_MAX_NUMA_NODES=1
> +CONFIG_RTE_EAL_IGB_UIO=n
I think it makes sense to move this option to generic arm64 config
as upstream arm64 kernel does not have support for sysfs based PCI mmap
resource file,(/sys/bus/pci/devices/B:D:F/resource[_wc]X) need for
CONFIG_RTE_EAL_IGB_UIO to work) and use VFIO for all cases.

Any objections?

Make sense. IGB_UIO for arm64 is NA.
+1
I can take care of it in next version of patch


> +CONFIG_RTE_EAL_VFIO=y
> diff --git a/mk/machine/dpaa2/rte.vars.mk<http://rte.vars.mk> 
> b/mk/machine/dpaa2/rte.vars.mk<http://rte.vars.mk>
> new file mode 100644
> index 000..8541633
> --- /dev/null
> +++ b/mk/machine/dpaa2/rte.vars.mk<http://rte.vars.mk>
> @@ -0,0 +1,60 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2016 Freescale Semiconductor, Inc. All rights reserved.
> +#
> +#   Redistribution and use in source and binary forms, with or without
> +#   modification, are permitted provided that the following conditions
> +#   are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +#   notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +#   notice, this list of conditions and the following disclaimer in
> +#  

[dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on armv8-a

[Hemant Agrawal]

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Monday, May 09, 2016 2:10 PM
To: Hemant Agrawal 
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: Introduce NXP dpaa2 architecture based on 
armv8-a

2016-05-09 19:18, Hemant Agrawal:
> This patch introduces dpaa2 machine target to address difference in 
> cpu parameter, number of core to 8 and no numa support w.r.t default 
> armv8-a machine
> 
> Signed-off-by: Hemant Agrawal 
[...]
> --- /dev/null
> +++ b/mk/machine/dpaa2/rte.vars.mk
> +# ARCH =
> +# CROSS =
> +# MACHINE_CFLAGS =
> +# MACHINE_LDFLAGS =
> +# MACHINE_ASFLAGS =
> +# CPU_CFLAGS =
> +# CPU_LDFLAGS =
> +# CPU_ASFLAGS =
> +MACHINE_CFLAGS += -march=armv8-a
> +
> +ifdef CONFIG_RTE_ARCH_ARM_TUNE
> +MACHINE_CFLAGS += -mcpu=$(CONFIG_RTE_ARCH_ARM_TUNE) endif

There is nothing specific in this file.
[Hemant] The arch is "armv8-a" instead of "armv8-a+crc".  Also, we are using 
"mcpu" for ARM tuning. This is not present in the armv8a machine. The armv7a 
machine usages RTE_ARCH_ARM_TUNE to configure "mtune". 

> --- a/mk/rte.module.mk
> +++ b/mk/rte.module.mk
> + Linaro toolchain usages arm64 instread of aarch64 in kernel ifeq 
> +($(ARCH), aarch64) ARCH = arm64 endif

Could you provide more explanations please?
aarch64 shouldn't be used I think.
[Hemant] you are right. This is not required. I was using an old toolchain. 

[dpdk-dev] [PATCH] kni:optimization of rte_kni_rx_burst

[Hemant Agrawal]

From: Hemant Agrawal <hem...@freescale.com>

if any buffer is read from the tx_q, MAX_BURST buffers will be allocated and 
attempted to be added to to the alloc_q.
This seems terribly inefficient and it also looks like the alloc_q will quickly 
fill to its maximum capacity. If the system buffers are low in number, it will 
reach "out of memory" situation.

This patch allocates the number of buffers as many dequeued from tx_q.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_kni/rte_kni.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 4e70fa0..4cf8e30 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -128,7 +128,7 @@ struct rte_kni_memzone_pool {


 static void kni_free_mbufs(struct rte_kni *kni);
-static void kni_allocate_mbufs(struct rte_kni *kni);
+static void kni_allocate_mbufs(struct rte_kni *kni, int num);

 static volatile int kni_fd = -1;
 static struct rte_kni_memzone_pool kni_memzone_pool = {
@@ -575,7 +575,7 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf 
**mbufs, unsigned num)

/* If buffers removed, allocate mbufs and then put them into alloc_q */
if (ret)
-   kni_allocate_mbufs(kni);
+   kni_allocate_mbufs(kni, ret);

return ret;
 }
@@ -594,7 +594,7 @@ kni_free_mbufs(struct rte_kni *kni)
 }

 static void
-kni_allocate_mbufs(struct rte_kni *kni)
+kni_allocate_mbufs(struct rte_kni *kni, int num)
 {
int i, ret;
struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];
@@ -620,7 +620,10 @@ kni_allocate_mbufs(struct rte_kni *kni)
return;
}

-   for (i = 0; i < MAX_MBUF_BURST_NUM; i++) {
+   if (num == 0 || num > MAX_MBUF_BURST_NUM)
+   num = MAX_MBUF_BURST_NUM;
+
+   for (i = 0; i < num; i++) {
pkts[i] = rte_pktmbuf_alloc(kni->pktmbuf_pool);
if (unlikely(pkts[i] == NULL)) {
/* Out of memory */
@@ -636,7 +639,7 @@ kni_allocate_mbufs(struct rte_kni *kni)
ret = kni_fifo_put(kni->alloc_q, (void **)pkts, i);

/* Check if any mbufs not put into alloc_q, and then free them */
-   if (ret >= 0 && ret < i && ret < MAX_MBUF_BURST_NUM) {
+   if (ret >= 0 && ret < i && ret < num) {
int j;

for (j = ret; j < i; j++)
-- 
1.9.1

[dpdk-dev] [PATCH] kni: optimizing the rte_kni_rx_burst

[Hemant Agrawal]

The current implementation of rte_kni_rx_burst polls the fifo for buffers.
Irrespective of success or failure, it allocates the mbuf and try to put them 
into the alloc_q
if the buffers are not added to alloc_q, it frees them.
This waste lots of cpu cycles in allocating and freeing the buffers if alloc_q 
is full.

The logic has been changed to:
1. Initially allocand add buffer(burstsize) to alloc_q
2. Add buffers to alloc_q only when you are pulling out the buffers.

Signed-off-by: Hemant Agrawal 
---
 lib/librte_kni/rte_kni.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 76feef4..01e85f8 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -263,6 +263,9 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,

ctx->in_use = 1;

+   /* Allocate mbufs and then put them into alloc_q */
+   kni_allocate_mbufs(ctx);
+
return ctx;

 fail:
@@ -369,8 +372,9 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf 
**mbufs, unsigned num)
 {
unsigned ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);

-   /* Allocate mbufs and then put them into alloc_q */
-   kni_allocate_mbufs(kni);
+   /* If buffers removed, allocate mbufs and then put them into alloc_q */
+   if(ret)
+   kni_allocate_mbufs(kni);

return ret;
 }
-- 
1.7.9.6