From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <huawei.xie@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id E80E22BDA
for <dev@dpdk.org>; Mon, 7 Mar 2016 03:55:58 +0100 (CET)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
by orsmga101.jf.intel.com with ESMTP; 06 Mar 2016 18:55:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,549,1449561600"; d="scan'208";a="918241222"
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
by fmsmga001.fm.intel.com with ESMTP; 06 Mar 2016 18:55:58 -0800
Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by
FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Sun, 6 Mar 2016 18:55:56 -0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Sun, 6 Mar 2016 18:55:56 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by
shsmsx102.ccr.corp.intel.com ([169.254.2.232]) with mapi id 14.03.0248.002;
Mon, 7 Mar 2016 10:55:54 +0800
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Thread-Topic: [PATCH v2 1/7] vhost: refactor rte_vhost_dequeue_burst
Thread-Index: AdF1cN/OclXhimYJTx2/yKoyh8rOiw==
Date: Mon, 7 Mar 2016 02:55:54 +0000
Message-ID: <C37D651A908B024F974696C65296B57B4C637039@SHSMSX101.ccr.corp.intel.com>
References: <1449122773-25510-1-git-send-email-yuanhan.liu@linux.intel.com>
<1455803352-5518-1-git-send-email-yuanhan.liu@linux.intel.com>
<1455803352-5518-2-git-send-email-yuanhan.liu@linux.intel.com>
<C37D651A908B024F974696C65296B57B4C62709B@SHSMSX101.ccr.corp.intel.com>
<20160304021154.GS14300@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
Cc: "Michael S. Tsirkin" <mst@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>,
Victor Kaplansky <vkaplans@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/7] vhost: refactor
rte_vhost_dequeue_burst
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Mon, 07 Mar 2016 02:55:59 -0000
On 3/4/2016 10:10 AM, Yuanhan Liu wrote:=0A=
> On Thu, Mar 03, 2016 at 05:19:42PM +0000, Xie, Huawei wrote:=0A=
>> On 2/18/2016 9:48 PM, Yuanhan Liu wrote:=0A=
>>> [...]=0A=
>> CCed changchun, the author for the chained handling of desc and mbuf.=0A=
>> The change makes the code more readable, but i think the following=0A=
>> commit message is simple and enough.=0A=
> Hmm.., my commit log tells a full story:=0A=
>=0A=
> - What is the issue? (messy/logic twisted code)=0A=
>=0A=
> - What the code does? (And what are the challenges: few tricky places)=0A=
>=0A=
> - What's the proposed solution to fix it. (the below pseudo code)=0A=
>=0A=
> And you suggest me to get rid of the first 2 items and leave 3rd item=0A=
> (a solution) only?=0A=
=0A=
The following are simple and enough with just one additional statement=0A=
for the repeated mbuf allocation or your twisted. Other commit messages=0A=
are overly duplicated. Just my personal opinion. Up to you.=0A=
=0A=
To this special case, for example, we could make both mbuf and=0A=
vring_desc chains into iovec, then use commonly used iovec copy=0A=
algorithms for both dequeue and enqueue, which further makes the code=0A=
much simpler and more readable. For this change, one or two sentences=0A=
are clear to me.=0A=
=0A=
> --yliu=0A=
>=0A=
>>> while (this_desc_is_not_drained_totally || has_next_desc) {=0A=
>>> if (this_desc_has_drained_totally) {=0A=
>>> this_desc =3D next_desc();=0A=
>>> }=0A=
>>>=0A=
>>> if (mbuf_has_no_room) {=0A=
>>> mbuf =3D allocate_a_new_mbuf();=0A=
>>> }=0A=
>>>=0A=
>>> COPY(mbuf, desc);=0A=
>>> }=0A=
>>>=0A=
>>> [...]=0A=
>>>=0A=
>>> This refactor makes the code much more readable (IMO), yet it reduces=
=0A=
>>> binary code size (nearly 2K).=0A=
>> I guess the reduced binary code size comes from reduced inline calls to=
=0A=
>> mbuf allocation.=0A=
>>=0A=
=0A=