From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2CF1128F3 for ; Wed, 11 Jan 2017 02:28:35 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 10 Jan 2017 17:28:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,345,1477983600"; d="scan'208";a="1081559337" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga001.jf.intel.com with ESMTP; 10 Jan 2017 17:28:34 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 Jan 2017 17:28:34 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 10 Jan 2017 17:28:34 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002; Wed, 11 Jan 2017 09:28:30 +0800 From: "Wang, Zhihong" To: Thomas Monjalon CC: Ravi Kerur , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions Thread-Index: AQHReMVAwLpgxle4AUi4lce7uR+4BZ/LY3twgBFoO4CAAZnDwIFIk/iAgApsFiD///RdgIADCB0g Date: Wed, 11 Jan 2017 01:28:30 +0000 Message-ID: <8F6C2BD409508844A0EFC19955BE094151201872@SHSMSX103.ccr.corp.intel.com> References: <1457391583-29604-1-git-send-email-rkerur@gmail.com> <1828046.HL686xpgu5@xps13> <8F6C2BD409508844A0EFC19955BE0941512003E4@SHSMSX103.ccr.corp.intel.com> <3403725.gYqeoHWGyH@xps13> In-Reply-To: <3403725.gYqeoHWGyH@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 01:28:35 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, January 9, 2017 7:09 PM > To: Wang, Zhihong > Cc: Ravi Kerur ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1 2/2] Test cases for rte_memcmp > functions >=20 > 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 kno= w 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. >=20 > 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.