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 E5E636A8B for ; Tue, 30 Sep 2014 05:34:50 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 29 Sep 2014 20:41:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,624,1406617200"; d="scan'208";a="581009457" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 29 Sep 2014 20:41:28 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 20:41:28 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 29 Sep 2014 20:41:28 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.192]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.230]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 11:41:25 +0800 From: "Ouyang, Changchun" To: "Xie, Huawei" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge Oliver's mbuf change Thread-Index: AQHP3FgkrbGy4bN0JUG73T6fynf+PpwZBLMQ Date: Tue, 30 Sep 2014 03:41:24 +0000 Message-ID: References: <1411724758-27488-1-git-send-email-huawei.xie@intel.com> <1411724758-27488-6-git-send-email-huawei.xie@intel.com> <9382804.Ypo5if4EZ6@xps13> In-Reply-To: Accept-Language: zh-CN, 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: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge Oliver's mbuf change 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: Tue, 30 Sep 2014 03:34:51 -0000 Hi Huawei, My response as below. Thanks Changchun > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Xie, Huawei > Sent: Tuesday, September 30, 2014 10:41 AM > To: Thomas Monjalon > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge Oliver's > mbuf change >=20 > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Tuesday, September 30, 2014 3:44 AM > > To: Xie, Huawei > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge > > Oliver's mbuf change > > > > > There is no rte_pktmbuf structure in mbuf now. Its fields are merged > > > to rte_mbuf structure. > > > > > > Signed-off-by: Huawei Xie > > > > This patch shouldn't appear but should be merged with your previous wor= k. > > > > -- > > Thomas >=20 > Hi Thomas: > I would rework the patch according to your comment. > I don't get clear about this comment. Do you mean that recreate the patch > set based on the example that already has this mbuf change? My understanding is as follows: Basically every patch file need base on the latest commit, so need merge al= l changes which have already been applied into mainline, No only mbuf related change and mergeable feature but also other fix. "git fetch" and "git pull origin master" may help you,=20 If there are conflicts, need resolve them. And you don't need redo all works from scratch to regenerate the patch file= s,=20 Maybe based on your current commit and do the merge work and resolve some c= onflicts are the most rework task. =20 >=20 > Some of the background you might not know: > I fully understand your concern here to make it a better patch and I full= y > agree with you total comments. > This is really a special case. You know it is transform of thousand lines= of code > with modifications. > Sometimes a simple change could take me more than one day to rework the > patch, lines of lines manual check. > I have already spent more than one week of time merely on the patch > format itself. :(. >=20 > Could we possibly treat it specially when we have comment whether the > patch can be split/merged better?