[dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge Oliver's mbuf change

[Ouyang, Changchun]

Hi Huawei,

My response as below.
Thanks
Changchun

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xie, Huawei
> Sent: Tuesday, September 30, 2014 10:41 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 05/11] lib/librte_vhost: merge Oliver's
> mbuf change
> 
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Tuesday, September 30, 2014 3:44 AM
> > To: Xie, Huawei
> > Cc: dev at 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 <huawei.xie at intel.com>
> >
> > This patch shouldn't appear but should be merged with your previous work.
> >
> > --
> > Thomas
> 
> 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 all 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, 
If there are conflicts, need resolve them.

And you don't need redo all works from scratch to regenerate the patch files, 
Maybe based on your current commit and do the merge work and resolve some conflicts are the most rework task.
 
> 
> Some of the background you might not know:
> I fully understand your concern here to make it a better patch and I fully
> 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. :(.
> 
> Could we possibly treat it specially when we have comment whether the
> patch can be split/merged better?