DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matt Laswell <laswell@infiniteio.com>
To: Ravi Kerur <rkerur@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp using AVX/SSE instructions.
Date: Fri, 8 May 2015 18:25:10 -0500	[thread overview]
Message-ID: <CA+GnqAqjJ2v_vjZq57B1girRjuozud1rGEDgma9+VfX0h7LPhw@mail.gmail.com> (raw)
In-Reply-To: <CAFb4SLCWryvzzmBVp=QTE5LxWTudDh--ZVduZtyK8ThPRfTkWw@mail.gmail.com>

On Fri, May 8, 2015 at 5:54 PM, Ravi Kerur <rkerur@gmail.com> wrote:

>
>
> 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.
>

Ah, gotcha.  I misunderstood and thought that this was meant to be a
generic AVX/SSE enabled memcmp() replacement, and that the use of it in
rte_hash was meant merely as a test case.   If it's more limited than that,
carry on, though you might want to make a note of it in the documentation.
I suspect others will misinterpret the name as I did.

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

  reply	other threads:[~2015-05-08 23:25 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 [this message]
2015-05-11  9:51       ` Ananyev, Konstantin
2015-05-11 17:42         ` Ravi Kerur
     [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=CA+GnqAqjJ2v_vjZq57B1girRjuozud1rGEDgma9+VfX0h7LPhw@mail.gmail.com \
    --to=laswell@infiniteio.com \
    --cc=dev@dpdk.org \
    --cc=rkerur@gmail.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).