From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Mon, 9 Jan 2017 12:08:59 +0100 (CET) Received: by mail-wj0-f182.google.com with SMTP id tn15so63728659wjb.1 for ; Mon, 09 Jan 2017 03:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=OApWB2qIbAa5MLGvJ2PtwJpn3DbgTApvLdAL13eiuSY=; b=VDzxQmpipVNa6SVYzgyH2r2pEHghg2mmm+6MEC8kLiCQSoAbID3FkWNU5EWZhsC+Qk pr2f2DyjhvcK4UCARgzNXysDr+DLyxo/rk9PRw0XjfVkOn7Iv1uyW3N6sVjzSvBbgehZ fi8xHa+2aUMlLfZw54vIV7Km6IHwHYXWsgFXhqdNTSLVTWIcWhR5/LrSFRibdSyvutgE kOxZsExoLsNhLMz4TrnVfL6tOaf3NfJ1UHeEs7ZA/A40Vmwrn1pLeFF2fFBuinDxkZzY U1af45mwodELEagdiHp2KnKKeOemC5xC1Uiypk8wcWcbMpyKEN3dbO9ywq33I0J7+iKz tMYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=OApWB2qIbAa5MLGvJ2PtwJpn3DbgTApvLdAL13eiuSY=; b=hbqzuVjFrTPf078rYnA0mjebbSBAt6Ebp1ZGj7j6zLm03mZca+O2GxiiKuBRFngWRr FoNTtJWDTi4I8RIle7nYDhH4TU0bzmeM7DxjnPeC7bl3/3aN94bqgJXl8+/M2oDUZKD2 Gss1eWVUh9vq7yzwa19XpfebDjGtpMV3ll2wm4TeHcyZWPmQytFptuNGFsbhsREj4Iza df1uzDmZWSrfZLJUHXsclnJWBRdcTV1siriWGNbsiFyH9kzJXWJo4Zrxi4a0Lc5Fe4g2 auwjftCWOjhKM0DC+S28FmCAdXq3B5qh2LZM45EpdNnHVVIcBdjZ0KNaPATGoWZgjr7V 36kQ== X-Gm-Message-State: AIkVDXLmp5yREb13dhQ1kjCxcQSR/GNPlhMdSMOUmOzdXod6imNX49gNxdLCWQrlabkRJHPS X-Received: by 10.194.37.130 with SMTP id y2mr3028558wjj.79.1483960139140; Mon, 09 Jan 2017 03:08:59 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id b3sm123200649wjy.40.2017.01.09.03.08.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 03:08:58 -0800 (PST) From: Thomas Monjalon To: "Wang, Zhihong" Cc: Ravi Kerur , dev@dpdk.org Date: Mon, 09 Jan 2017 12:08:57 +0100 Message-ID: <3403725.gYqeoHWGyH@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <8F6C2BD409508844A0EFC19955BE0941512003E4@SHSMSX103.ccr.corp.intel.com> References: <1457391583-29604-1-git-send-email-rkerur@gmail.com> <1828046.HL686xpgu5@xps13> <8F6C2BD409508844A0EFC19955BE0941512003E4@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Mon, 09 Jan 2017 11:08:59 -0000 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.