DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ravi Kerur <rkerur@gmail.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp using AVX/SSE instructions.
Date: Mon, 11 May 2015 10:42:51 -0700	[thread overview]
Message-ID: <CAFb4SLCZdHNpiBLA5nO4o1BCDJC=Q=cszL9AX5_kyAnatB9rdA@mail.gmail.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772582142E106@irsmsx105.ger.corp.intel.com>

Hi Konstantin,


On Mon, May 11, 2015 at 2:51 AM, Ananyev, Konstantin <
konstantin.ananyev@intel.com> wrote:

> Hi Ravi,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ravi Kerur
> > Sent: Friday, May 08, 2015 11:55 PM
> > To: Matt Laswell
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp using AVX/SSE
> instructions.
> >
> > On Fri, May 8, 2015 at 3:29 PM, Matt Laswell <laswell@infiniteio.com>
> wrote:
> >
> > >
> > >
> > > On Fri, May 8, 2015 at 4:19 PM, Ravi Kerur <rkerur@gmail.com> wrote:
> > >
> > >> This patch replaces memcmp in librte_hash with rte_memcmp which is
> > >> implemented with AVX/SSE instructions.
> > >>
> > >> +static inline int
> > >> +rte_memcmp(const void *_src_1, const void *_src_2, size_t n)
> > >> +{
> > >> +       const uint8_t *src_1 = (const uint8_t *)_src_1;
> > >> +       const uint8_t *src_2 = (const uint8_t *)_src_2;
> > >> +       int ret = 0;
> > >> +
> > >> +       if (n & 0x80)
> > >> +               return rte_cmp128(src_1, src_2);
> > >> +
> > >> +       if (n & 0x40)
> > >> +               return rte_cmp64(src_1, src_2);
> > >> +
> > >> +       if (n & 0x20) {
> > >> +               ret = rte_cmp32(src_1, src_2);
> > >> +               n -= 0x20;
> > >> +               src_1 += 0x20;
> > >> +               src_2 += 0x20;
> > >> +       }
> > >>
> > >>
> > > Pardon me for butting in, but this seems incorrect for the first two
> cases
> > > listed above, as the function as written will only compare the first
> 128 or
> > > 64 bytes of each source and return the result.  The pattern expressed
> in
> > > the 32 byte case appears more correct, as it compares the first 32
> bytes
> > > and then lets later pieces of the function handle the smaller remaining
> > > bits of the sources. Also, if this function is to handle arbitrarily
> large
> > > source data, the 128 byte case needs to be in a loop.
> > >
> > > What am I missing?
> > >
> >
> > Current max hash key length supported is 64 bytes, hence no comparison is
> > done after 64 bytes. 128 bytes comparison is added to measure performance
> > only and there is no use-case as of now. With the current use-cases its
> not
> > required but if there is a need to handle large arbitrary data upto 128
> > bytes it can be modified.
>
> So on x86 let say rte_memcmp(k1, k2, 65) might produce invalid results,
> right?
> While on PPC will work as expected (as it calls memcpu underneath)?
> That looks really weird to me.
> If you plan to use rte_memcmp only for hash comparisons, then probably
> you should put it somewhere into librte_hash and name it accordingly:
> rte_hash_key_cmp() or something.
> And put a big comment around it, that it only works with particular
> lengths.
> If you want it to be a generic function inside EAL, then it probably need
> to handle different lengths properly
> on all supported architectures.
> Konstantin
>
>
Let me just explain it here and probably add it to document as well.

rte_memcmp is not

1. a replacement to memcmp

2.  restricted to hash key comparison

rte_memcmp is

1. optimized comparison for 16 to 128 bytes, v1 patch series had this
support. Changed some of the logic in v2 due to concerns raised for
unavailable use-cases beyond 64 bytes comparison. With minor tuning over
the weekend I am able to get better performance for anything between 16 to
128 bytes comparison.

2. will be specific to DPDK  i.e. currently all memcmp usage in DPDK are
for equality or inequality hence "less than" or "greater than"
implementation in rte_memcmp doesn't make sense and will be removed in
subsequent patches, it will return 0 or 1 for equal/unequal cases.

rte_hash will be the first candidate to move to rte_memcmp and subsequently
rte_lpm6 which uses 16 bytes comparison will be moved

Later on RING_SIZE which uses large size for comparison will be moved. I am
currently studying/understanding that logic and will make changes to
rte_memcmp to support that.

I don't want to make lot of changes in one shot and see that patch series
die a slow death with no takers.

Thanks,
Ravi

>
> > >
> > > --
> > > Matt Laswell
> > > infinite io, inc.
> > > laswell@infiniteio.com
> > >
> > >
>

  reply	other threads:[~2015-05-11 17:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08 21:19 [dpdk-dev] [PATCH v2] Implement rte_memcmp with " Ravi Kerur
2015-05-08 21:19 ` [dpdk-dev] [PATCH v2] Implement memcmp using " Ravi Kerur
2015-05-08 22:29   ` Matt Laswell
2015-05-08 22:54     ` Ravi Kerur
2015-05-08 23:25       ` Matt Laswell
2015-05-11  9:51       ` Ananyev, Konstantin
2015-05-11 17:42         ` Ravi Kerur [this message]
     [not found]           ` <2601191342CEEE43887BDE71AB9772582142E44A@irsmsx105.ger.corp.intel.com>
2015-05-11 19:35             ` Ananyev, Konstantin
2015-05-11 20:46               ` Ravi Kerur
2015-05-11 22:29                 ` Don Provan
2015-05-13  1:16                   ` Ravi Kerur
2015-05-13  9:03                     ` Bruce Richardson
2015-05-13 20:08                       ` Ravi Kerur
2015-05-13 12:21                     ` Jay Rolette
2015-05-13 20:07                       ` Ravi Kerur
     [not found]                 ` <2601191342CEEE43887BDE71AB9772582142EBB5@irsmsx105.ger.corp.intel.com>
2015-05-13 10:12                   ` Ananyev, Konstantin
2015-05-13 20:06                     ` Ravi Kerur
2015-05-12  8:13   ` Linhaifeng
2015-05-13  1:18     ` Ravi Kerur
2015-05-13  7:22       ` Linhaifeng
2015-05-13 20:00         ` Ravi Kerur

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='CAFb4SLCZdHNpiBLA5nO4o1BCDJC=Q=cszL9AX5_kyAnatB9rdA@mail.gmail.com' \
    --to=rkerur@gmail.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    /path/to/YOUR_REPLY

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

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