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 E80E22BDA for ; 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" To: Yuanhan Liu 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: 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> <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" , "dev@dpdk.org" , Victor Kaplansky 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=