DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Jianbo Liu <jianbo.liu@linaro.org>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic
Date: Mon, 7 Dec 2015 12:27:34 +0530	[thread overview]
Message-ID: <20151207065731.GA2897@localhost.localdomain> (raw)
In-Reply-To: <CAP4Qi39uOq-NZcx3N0nDs7gjFaF_YWST0XK6c2XSOLigascdzQ@mail.gmail.com>

On Mon, Dec 07, 2015 at 02:15:28PM +0800, Jianbo Liu wrote:
> On 4 December 2015 at 23:14, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> > -Used architecture agnostic xmm_t to represent 128 bit SIMD variable
> >
> > -Introduced vect_* API abstraction in app/test to test rte_lpm_lookupx4
> > API in  architecture agnostic way
> >
> > -Moved rte_lpm_lookupx4 SSE implementation to architecture specific
> > rte_lpm_sse.h file to accommodate new rte_lpm_lookupx4 implementation
> > for a different architecture.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> >  app/test/test_lpm.c          |  21 ++++---
> >  app/test/test_xmmt_ops.h     |  47 ++++++++++++++
> >  lib/librte_lpm/Makefile      |   2 +
> >  lib/librte_lpm/rte_lpm.h     |  93 +---------------------------
> >  lib/librte_lpm/rte_lpm_sse.h | 143 +++++++++++++++++++++++++++++++++++++++++++
> >  5 files changed, 206 insertions(+), 100 deletions(-)
> >  create mode 100644 app/test/test_xmmt_ops.h
> >  create mode 100644 lib/librte_lpm/rte_lpm_sse.h
> >
> > diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
> > index 8b4ded9..59674f1 100644
> > --- a/app/test/test_lpm.c
> > +++ b/app/test/test_lpm.c
> > @@ -49,6 +49,7 @@
> >
> >  #include "rte_lpm.h"
> >  #include "test_lpm_routes.h"
> > +#include "test_xmmt_ops.h"
> >
> >  #define TEST_LPM_ASSERT(cond) do {                                            \
> >         if (!(cond)) {                                                        \
> > @@ -308,7 +309,7 @@ test6(void)
> >  int32_t
> >  test7(void)
> >  {
> > -       __m128i ipx4;
> > +       xmm_t ipx4;
> >         uint16_t hop[4];
> >         struct rte_lpm *lpm = NULL;
> >         uint32_t ip = IPv4(0, 0, 0, 0);
> > @@ -324,7 +325,7 @@ test7(void)
> >         status = rte_lpm_lookup(lpm, ip, &next_hop_return);
> >         TEST_LPM_ASSERT((status == 0) && (next_hop_return == next_hop_add));
> >
> > -       ipx4 = _mm_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> > +       ipx4 = vect_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> >         rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> >         TEST_LPM_ASSERT(hop[0] == next_hop_add);
> >         TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
> > @@ -354,7 +355,7 @@ test7(void)
> >  int32_t
> >  test8(void)
> >  {
> > -       __m128i ipx4;
> > +       xmm_t ipx4;
> >         uint16_t hop[4];
> >         struct rte_lpm *lpm = NULL;
> >         uint32_t ip1 = IPv4(127, 255, 255, 255), ip2 = IPv4(128, 0, 0, 0);
> > @@ -380,7 +381,7 @@ test8(void)
> >                 TEST_LPM_ASSERT((status == 0) &&
> >                         (next_hop_return == next_hop_add));
> >
> > -               ipx4 = _mm_set_epi32(ip2, ip1, ip2, ip1);
> > +               ipx4 = vect_set_epi32(ip2, ip1, ip2, ip1);
> >                 rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> >                 TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> >                 TEST_LPM_ASSERT(hop[1] == next_hop_add);
> > @@ -408,7 +409,7 @@ test8(void)
> >                 status = rte_lpm_lookup(lpm, ip1, &next_hop_return);
> >                 TEST_LPM_ASSERT(status == -ENOENT);
> >
> > -               ipx4 = _mm_set_epi32(ip1, ip1, ip2, ip2);
> > +               ipx4 = vect_set_epi32(ip1, ip1, ip2, ip2);
> >                 rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> >                 if (depth != 1) {
> >                         TEST_LPM_ASSERT(hop[0] == next_hop_add);
> > @@ -850,7 +851,7 @@ test11(void)
> >  int32_t
> >  test12(void)
> >  {
> > -       __m128i ipx4;
> > +       xmm_t ipx4;
> >         uint16_t hop[4];
> >         struct rte_lpm *lpm = NULL;
> >         uint32_t ip, i;
> > @@ -872,7 +873,7 @@ test12(void)
> >                 TEST_LPM_ASSERT((status == 0) &&
> >                                 (next_hop_return == next_hop_add));
> >
> > -               ipx4 = _mm_set_epi32(ip, ip + 1, ip, ip - 1);
> > +               ipx4 = vect_set_epi32(ip, ip + 1, ip, ip - 1);
> >                 rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> >                 TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> >                 TEST_LPM_ASSERT(hop[1] == next_hop_add);
> > @@ -1289,10 +1290,10 @@ perf_test(void)
> >                 begin = rte_rdtsc();
> >                 for (j = 0; j < BATCH_SIZE; j += RTE_DIM(next_hops)) {
> >                         unsigned k;
> > -                       __m128i ipx4;
> > +                       xmm_t ipx4;
> >
> > -                       ipx4 = _mm_loadu_si128((__m128i *)(ip_batch + j));
> > -                       ipx4 = *(__m128i *)(ip_batch + j);
> > +                       ipx4 = vect_loadu_sil128((xmm_t *)(ip_batch + j));
> > +                       ipx4 = *(xmm_t *)(ip_batch + j);
> >                         rte_lpm_lookupx4(lpm, ipx4, next_hops, UINT16_MAX);
> >                         for (k = 0; k < RTE_DIM(next_hops); k++)
> >                                 if (unlikely(next_hops[k] == UINT16_MAX))
> > diff --git a/app/test/test_xmmt_ops.h b/app/test/test_xmmt_ops.h
> > new file mode 100644
> > index 0000000..c055912
> > --- /dev/null
> > +++ b/app/test/test_xmmt_ops.h
> Why add this new file under app/test, which is only for test app?
> Should vect_loadu_sil128/vect_set_epi32 be in each ARCH's rte_vect.h?
>

V1 was like that, I thought of moving the file under app/test because

1) all the ARCH can't have the implementation for vector primitives if
architecture doesn't support it like ppc64 and tile so moving EAL may
not be a good idea
2) scope of vector abstraction only for using the API(i.e test app), NOT
for
implementing the library. So its boils down to load/store/set should
not be beyond that.
and I am afraid that if we opening up EAL abstraction that will change the scope
and which will have performance implication to use emulating the logic in
library
3) It's been discussed, There was no disagreement on this
http://dpdk.org/ml/archives/dev/2015-December/029404.html

Thanks,
Jerin

[snip]

  reply	other threads:[~2015-12-07  6:58 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-30 17:24 [dpdk-dev] [PATCH 0/3] add lpm support for NEON Jerin Jacob
2015-11-30 17:24 ` [dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions Jerin Jacob
2015-12-02 13:43   ` Jan Viktorin
2015-12-02 14:51     ` Jerin Jacob
2015-11-30 17:24 ` [dpdk-dev] [PATCH 2/3] lpm: add support for NEON Jerin Jacob
2015-12-02 13:43   ` Jan Viktorin
2015-12-02 14:56     ` Jerin Jacob
2015-12-02 15:00       ` Jan Viktorin
2015-11-30 17:24 ` [dpdk-dev] [PATCH 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm Jerin Jacob
2015-12-02 13:43   ` Jan Viktorin
2015-12-02 14:57     ` Jerin Jacob
2015-12-02 13:43 ` [dpdk-dev] [PATCH 0/3] add lpm support for NEON Jan Viktorin
2015-12-02 14:41   ` Jerin Jacob
2015-12-04 15:14 ` [dpdk-dev] [PATCH v2 " Jerin Jacob
2015-12-04 15:14   ` [dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic Jerin Jacob
2015-12-07  6:15     ` Jianbo Liu
2015-12-07  6:57       ` Jerin Jacob [this message]
2015-12-07 14:06     ` Ananyev, Konstantin
2015-12-04 15:14   ` [dpdk-dev] [PATCH v2 2/3] lpm: add support for NEON Jerin Jacob
2015-12-04 15:14   ` [dpdk-dev] [PATCH v2 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm Jerin Jacob
2016-01-29  4:10   ` [dpdk-dev] [PATCH v3 0/3] add lpm support for NEON Jerin Jacob
2016-01-29  4:10     ` [dpdk-dev] [PATCH v3 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic Jerin Jacob
2016-01-29  4:10     ` [dpdk-dev] [PATCH v3 2/3] lpm: add support for NEON Jerin Jacob
2016-02-11 11:46       ` Thomas Monjalon
2016-02-12  6:47         ` Jerin Jacob
2016-02-12  8:42           ` Thomas Monjalon
2016-01-29  4:10     ` [dpdk-dev] [PATCH v3 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm Jerin Jacob
2016-02-08  9:29     ` [dpdk-dev] [PATCH v3 0/3] add lpm support for NEON Jerin Jacob
2016-02-12 12:28     ` [dpdk-dev] [PATCH v4 " Jerin Jacob
2016-02-12 12:28       ` [dpdk-dev] [PATCH v4 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic Jerin Jacob
2016-03-01 17:42         ` Thomas Monjalon
2016-03-02  6:28           ` Jerin Jacob
2016-02-12 12:28       ` [dpdk-dev] [PATCH v4 2/3] lpm: add support for NEON Jerin Jacob
2016-03-01 17:46         ` Thomas Monjalon
2016-03-02  6:45           ` Jerin Jacob
2016-02-12 12:28       ` [dpdk-dev] [PATCH v4 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm Jerin Jacob
2016-03-01 17:47         ` Thomas Monjalon
2016-03-02  6:46           ` Jerin Jacob
2016-02-16 13:27       ` [dpdk-dev] [PATCH v4 0/3] add lpm support for NEON Kobylinski, MichalX
2016-02-16 16:44         ` Jerin Jacob
2016-02-18 10:26           ` Kobylinski, MichalX
2016-02-19  0:34             ` Jerin Jacob
2016-03-11  3:52       ` [dpdk-dev] [PATCH v5 " Jerin Jacob
2016-03-11  3:52         ` [dpdk-dev] [PATCH v5 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic Jerin Jacob
2016-03-11  3:52         ` [dpdk-dev] [PATCH v5 2/3] lpm: add support for NEON Jerin Jacob
2016-03-11  3:52         ` [dpdk-dev] [PATCH v5 3/3] Maintainers: claim responsibility for arm64 specific files of hash Jerin Jacob
2016-03-11 14:24         ` [dpdk-dev] [PATCH v5 0/3] add lpm support for NEON Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151207065731.GA2897@localhost.localdomain \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --cc=jianbo.liu@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).