I am preparing v5 patch for vhost lib and vhost example, merging the merge-able feature. The weird thing is merge-able feature ever works smoothly in my old code base which is based on 1.7.1, while after I merge with latest repo, mergeable could cause mbuf allocation failure. I did code comparison of vhost example and lib, the only change is the mbuf change. Debugging the issue.
> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Xie, Huawei > Sent: Thursday, September 25, 2014 11:10 AM > To: Thomas Monjalon > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4 0/5] lib/librte_vhost: user space vhost cuse > driver library > > > > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Thursday, September 25, 2014 12:22 AM > > To: Xie, Huawei > > Cc: dev at dpdk.org; Ouyang, Changchun > > Subject: Re: [dpdk-dev] [PATCH v4 0/5] lib/librte_vhost: user space vhost > > cuse > > driver library > > > > Hi, > > > > 2014-09-24 14:32, Ouyang, Changchun: > > > This v4 patch remove the jumbo frame related codes > > > and Huawei will add it back in a separate patch, > > > > I'd prefer a v5 which includes these changes. > > I know this patchset is pending and reworked many times, > > so I'll try to integrate v5 with top priority. > > > > Other comments: > > - examples/vhost/Makefile should not be copied (and removed just after) > > - coding style fixes are aligning things but antislashes are not well > > aligned > > "Anti-slashes alignment" issues are inherited from old code. > There are also hundreds of other serious coding style issues inherited. > I would send a separate patch to fix all those coding style issues after the > final > patch. Otherwise if i have to rework the patch, I have to redo the hundreds of > style > fixes line by line, which would take too much time, which is very inefficient. > > > > - fuse-devel and kernel-modules-extra packages are not available in > > this form in all distributions, it's better to describe what is behind > > these package names (especially for kernel-modules-extra) > > > > I won't have time to properly review the big refactoring. But I'm sure > > we'll better check it when using it once integrated. > > The essential is to be able to view the changes in the git history. > > Thanks for this effort. > > > > -- > > Thomas