From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zhihong.wang@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 161C22B8F
 for <dev@dpdk.org>; Wed,  7 Dec 2016 07:12:03 +0100 (CET)
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by orsmga103.jf.intel.com with ESMTP; 06 Dec 2016 22:12:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="39654941"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
 by orsmga005.jf.intel.com with ESMTP; 06 Dec 2016 22:12:02 -0800
Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by
 fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Tue, 6 Dec 2016 22:12:02 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
 FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Tue, 6 Dec 2016 22:12:02 -0800
Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.96]) by
 SHSMSX104.ccr.corp.intel.com ([169.254.5.142]) with mapi id 14.03.0248.002;
 Wed, 7 Dec 2016 14:12:00 +0800
From: "Wang, Zhihong" <zhihong.wang@intel.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, Thomas Monjalon <thomas.monjalon@6wind.com>
Thread-Topic: [PATCH] vhost: optimize vhost memcpy
Thread-Index: AQHSTHYyWBpmyoksL0mYHHQwaEW9IaD4g7oAgACkvPD//3+QgIADX0Ig
Date: Wed, 7 Dec 2016 06:11:59 +0000
Message-ID: <8F6C2BD409508844A0EFC19955BE09414E8007DD@SHSMSX103.ccr.corp.intel.com>
References: <1480641582-56186-1-git-send-email-zhihong.wang@intel.com>
 <20161205082714.GJ24403@yliu-dev.sh.intel.com>
 <8F6C2BD409508844A0EFC19955BE09414E7FF22D@SHSMSX103.ccr.corp.intel.com>
 <20161205103709.GL24403@yliu-dev.sh.intel.com>
In-Reply-To: <20161205103709.GL24403@yliu-dev.sh.intel.com>
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] vhost: optimize vhost memcpy
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Wed, 07 Dec 2016 06:12:04 -0000



> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Monday, December 5, 2016 6:37 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH] vhost: optimize vhost memcpy
>=20
> On Mon, Dec 05, 2016 at 10:27:00AM +0000, Wang, Zhihong wrote:
> > > I like this function a lot, since it's really simple and straightforw=
ard!
> > > Moreover, it performs better.
> > >
> > > But, I don't quite like how this function is proposed:
> > >
> > > - rte_movX are more like internal help functions that should be used =
only
> > >   in corresponding rte_memcpy.h file.
> > >
> > > - It's a good optimization, however, it will not benefit for other us=
e
> > >   cases, though vhost is the most typical case here.
> > >
> > > - The optimization proves to be good for X86, but think there is no
> > >   guarantee it may behave well for other platforms, say ARM.
> > >
> > > I still would suggest you to go this way: move this function into x86=
's
> > > rte_memcpy.h and call it when the data is well aligned.
> >
> >
> > Do you mean to add something like rte_memcpy_aligned() in
> > lib/librte_eal/common/include/generic/rte_memcpy.h?
>=20
> Yes, but this one is not supposed to be exported as a public API.
> It should be called inside rte_memcpy (when data is well aligned).
> In this way, only rte_memcpy is exposed, and nothing else should
> be changed.

Yes I agree this is a better way to introduce this patch, I'll send out v2.

>=20
> 	--yliu
> >
> > I thought of this way before, and didn't choose it because it requires
> > changes in eal. But it would be a clean solution, I'd certainly like
> > to implement it this way if people are okay with it.
> >
> >
> > Thanks
> > Zhihong
> >
> >
> > >
> > > 	--yliu