From: "Wang, Zhihong" <zhihong.wang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Ravi Kerur <rkerur@gmail.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions
Date: Wed, 11 Jan 2017 01:28:30 +0000 [thread overview]
Message-ID: <8F6C2BD409508844A0EFC19955BE094151201872@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <3403725.gYqeoHWGyH@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, January 9, 2017 7:09 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>
> Cc: Ravi Kerur <rkerur@gmail.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp
> functions
>
> 2017-01-09 05:29, Wang, Zhihong:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2016-06-07 11:09, Wang, Zhihong:
> > > > From: Ravi Kerur [mailto:rkerur@gmail.com]
> > > > > Zhilong, Thomas,
> > > > >
> > > > > If there is enough interest within DPDK community I can work on
> adding
> > > support
> > > > > for 'unaligned access' and 'test cases' for it. Please let me know either
> > > way.
> > > >
> > > > Hi Ravi,
> > > >
> > > > This rte_memcmp is proved with better performance than glibc's in
> aligned
> > > > cases, I think it has good value to DPDK lib.
> > > >
> > > > Though we don't have memcmp in critical pmd data path, it offers a
> better
> > > > choice for applications who do.
> > >
> > > Re-thinking about this series, could it be some values to have a
> rte_memcmp
> > > implementation?
> >
> > I think this series (rte_memcmp included) could help:
> >
> > 1. Potentially better performance in hot paths.
> >
> > 2. Agile for tuning.
> >
> > 3. Avoid performance complications -- unusual but possible,
> > like the glibc memset issue I met while working on vhost
> > enqueue.
> >
> > > What is the value compared to glibc one? Why not working on glibc?
> >
> > As to working on glibc, wider design consideration and test
> > coverage might be needed, and we'll face different release
> > cycles, can we have the same agility? Also working with old
> > glibc could be a problem.
>
> Probably we need both: add the optimized version in DPDK while working
> on a glibc optimization.
> This strategy could be applicable to memcpy, memcmp and memset.
This does help in the long run if turned out feasible.
next prev parent reply other threads:[~2017-01-11 1:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-07 22:59 [dpdk-dev] [PATCH v1 0/2] " Ravi Kerur
2016-03-07 23:00 ` [dpdk-dev] [PATCH v1 1/2] rte_memcmp functions using Intel AVX and SSE intrinsics Ravi Kerur
2016-03-07 23:00 ` [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions Ravi Kerur
2016-05-26 9:05 ` Wang, Zhihong
2016-06-06 18:31 ` Ravi Kerur
2016-06-07 11:09 ` Wang, Zhihong
2017-01-02 20:41 ` Thomas Monjalon
2017-01-09 5:29 ` Wang, Zhihong
2017-01-09 11:08 ` Thomas Monjalon
2017-01-11 1:28 ` Wang, Zhihong [this message]
2016-05-25 8:56 ` [dpdk-dev] [PATCH v1 1/2] rte_memcmp functions using Intel AVX and SSE intrinsics Thomas Monjalon
2016-05-26 8:57 ` Wang, Zhihong
2018-12-20 23:30 ` Ferruh Yigit
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=8F6C2BD409508844A0EFC19955BE094151201872@SHSMSX103.ccr.corp.intel.com \
--to=zhihong.wang@intel.com \
--cc=dev@dpdk.org \
--cc=rkerur@gmail.com \
--cc=thomas.monjalon@6wind.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).