From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH v1 2/2] Test cases for rte_memcmp functions
Date: Mon, 09 Jan 2017 12:08:57 +0100
Message-ID: <3403725.gYqeoHWGyH@xps13>
References: <1457391583-29604-1-git-send-email-rkerur@gmail.com>
 <1828046.HL686xpgu5@xps13>
 <8F6C2BD409508844A0EFC19955BE0941512003E4@SHSMSX103.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Ravi Kerur <rkerur@gmail.com>, dev@dpdk.org
To: "Wang, Zhihong" <zhihong.wang@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wj0-f182.google.com (mail-wj0-f182.google.com
 [209.85.210.182]) by dpdk.org (Postfix) with ESMTP id 73F0E1E2B
 for <dev@dpdk.org>; Mon,  9 Jan 2017 12:08:59 +0100 (CET)
Received: by mail-wj0-f182.google.com with SMTP id tn15so63728659wjb.1
 for <dev@dpdk.org>; Mon, 09 Jan 2017 03:08:59 -0800 (PST)
In-Reply-To: <8F6C2BD409508844A0EFC19955BE0941512003E4@SHSMSX103.ccr.corp.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.