From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [PATCH 4/5] vhost: do not use rte_memcpy for
	virtio_hdr copy
Date: Wed, 27 Jan 2016 14:02:36 +0800
Message-ID: <20160127060236.GG4257@yliu-dev.sh.intel.com>
References: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com>
 <1449122773-25510-5-git-send-email-yuanhan.liu@linux.intel.com>
 <C37D651A908B024F974696C65296B57B4C5AFED9@SHSMSX101.ccr.corp.intel.com>
 <20160127032245.GB4257@yliu-dev.sh.intel.com>
 <C37D651A908B024F974696C65296B57B4C5B04AB@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "dev@dpdk.org" <dev@dpdk.org>, Victor Kaplansky <vkaplans@redhat.com>,
 "Michael S. Tsirkin" <mst@redhat.com>
To: "Xie, Huawei" <huawei.xie@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
 by dpdk.org (Postfix) with ESMTP id 9CE3D93F2
 for <dev@dpdk.org>; Wed, 27 Jan 2016 07:02:12 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <C37D651A908B024F974696C65296B57B4C5B04AB@SHSMSX101.ccr.corp.intel.com>
List-Id: patches and discussions about DPDK <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>

On Wed, Jan 27, 2016 at 05:56:56AM +0000, Xie, Huawei wrote:
> On 1/27/2016 11:22 AM, Yuanhan Liu wrote:
> > On Wed, Jan 27, 2016 at 02:46:39AM +0000, Xie, Huawei wrote:
> >> On 12/3/2015 2:03 PM, Yuanhan Liu wrote:
> >>> +	if (vq->vhost_hlen == sizeof(struct virtio_net_hdr_mrg_rxbuf)) {
> >>> +		*(struct virtio_net_hdr_mrg_rxbuf *)(uintptr_t)desc_addr = hdr;
> >>> +	} else {
> >>> +		*(struct virtio_net_hdr *)(uintptr_t)desc_addr = hdr.hdr;
> >>> +	}
> >> Thanks!
> >> We might simplify this further. Just reset the first two fields flags
> >> and gso_type.
> > What's this "simplification" for? Don't even to say that we will add
> > TSO support, which modifies few more files, such as csum_start: reseting
> > the first two fields only is wrong here.
> 
> I know TSO before commenting, but at least in this implementation and
> this specific patch, i guess zeroing two fields are enough.
> 
> What is wrong resetting only two fields?

I then have to ask "What is the benifit of resetting only two fields"?
If doing so, we have to change it back for TSO. My proposal requires no
extra change when adding TSO support.

	--yliu