Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue

["Ouyang, Changchun" <changchun.ouyang@intel.com>]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, July 20, 2015 6:42 PM
> To: Ouyang, Changchun
> Cc: Xu, Qian Q; Stephen Hemminger; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue
> 
> 2015-07-20 06:18, Ouyang, Changchun:
> > Another thing burst into my thought.
> > Can we think more about how to setup a mechanism to block those
> patches which causes critical regression issue?
> 
> Yes. Non-regression tests are needed. As it must be done with many
> hardwares and many configurations, it must be a shared effort.
> As a first step, you can run some automated tests by yourself and
> *manually* raise errors on the mailing lists. When it will work well, we could
> discuss about gathering test reports in a clean distributed way.
> Note that this topic is already a work in progress by few people and a public
> proposal should be done in few weeks.

That's good. 

> 
> > I did review that patch before, but fail to realize it will break the basic
> function of virtio PMD, it is my bad.
> > (Can I send the nack to that patch even after it has been merged into
> > dpdk.org?)
> 
> After being approved and merged, a nack has no effect.
> Having a revert approved is the good way.

I have acked Stephen's new patch.

> 
> > After that, we find that in our testing cycle, we spend time in
> > investigating that and root the cause, and sent out the fixing patch on July 1.
> Keeping virtio basic functionality broken more than 20 days is bad thing for
> me.
> 
> It wouldn't be so long if these 3 simple things were done:
> - use a better title: "virtio: fix Rx from Qemu" instead of a not meaningful "fix
> the vq size issue"
> - cc Stephen (I did it later) who did the original patch you wants to revert
> - have an acked-by from Huawei Xie who commented the patch
> 
> > If we can run a regression automation test with every patch set sent
> > out to dpdk.org, and put those patches breaking any test cases Into
> > failing-list and notify author, reviewer and maintainer, all those things
> should be done before theirs being merged, then it will prevent from
> merging the erroneous patch into mainline, and thus reduce most reverting
> patch.
> 
> As explained above, it is planned and you can start running you own local test
> machine. But please do not spam the mailing list with automated mails from
> these tests.