From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 8C37A9412 for ; Wed, 27 Jan 2016 07:16:41 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP; 26 Jan 2016 22:16:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,353,1449561600"; d="scan'208";a="901944136" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 26 Jan 2016 22:16:40 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 26 Jan 2016 22:16:40 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 26 Jan 2016 22:16:39 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.215]) by shsmsx102.ccr.corp.intel.com ([169.254.2.172]) with mapi id 14.03.0248.002; Wed, 27 Jan 2016 14:16:38 +0800 From: "Xie, Huawei" To: Yuanhan Liu Thread-Topic: [PATCH 4/5] vhost: do not use rte_memcpy for virtio_hdr copy Thread-Index: AdFYrPIunwVMxkBCQWGWJqaoNIdiPQ== Date: Wed, 27 Jan 2016 06:16:37 +0000 Message-ID: References: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com> <1449122773-25510-5-git-send-email-yuanhan.liu@linux.intel.com> <20160127032245.GB4257@yliu-dev.sh.intel.com> <20160127060236.GG4257@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.4.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , Victor Kaplansky , "Michael S. Tsirkin" Subject: Re: [dpdk-dev] [PATCH 4/5] vhost: do not use rte_memcpy for virtio_hdr copy X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 06:16:42 -0000 On 1/27/2016 2:02 PM, Yuanhan Liu wrote:=0A= > On Wed, Jan 27, 2016 at 05:56:56AM +0000, Xie, Huawei wrote:=0A= >> On 1/27/2016 11:22 AM, Yuanhan Liu wrote:=0A= >>> On Wed, Jan 27, 2016 at 02:46:39AM +0000, Xie, Huawei wrote:=0A= >>>> On 12/3/2015 2:03 PM, Yuanhan Liu wrote:=0A= >>>>> + if (vq->vhost_hlen =3D=3D sizeof(struct virtio_net_hdr_mrg_rxbuf)) = {=0A= >>>>> + *(struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc_addr =3D hdr;= =0A= >>>>> + } else {=0A= >>>>> + *(struct virtio_net_hdr *)(uintptr_t)desc_addr =3D hdr.hdr;=0A= >>>>> + }=0A= >>>> Thanks!=0A= >>>> We might simplify this further. Just reset the first two fields flags= =0A= >>>> and gso_type.=0A= >>> What's this "simplification" for? Don't even to say that we will add=0A= >>> TSO support, which modifies few more files, such as csum_start: resetin= g=0A= >>> the first two fields only is wrong here.=0A= >> I know TSO before commenting, but at least in this implementation and=0A= >> this specific patch, i guess zeroing two fields are enough.=0A= >>=0A= >> What is wrong resetting only two fields?=0A= > I then have to ask "What is the benifit of resetting only two fields"?=0A= > If doing so, we have to change it back for TSO. My proposal requires no= =0A= > extra change when adding TSO support.=0A= =0A= ? Benefit is we save four unnecessary stores.=0A= =0A= >=0A= > --yliu=0A= >=0A= =0A=