Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Tue, Aug 05, 2014 at 05:50:42PM +0800, Ming Lei wrote:
> On Tue, Aug 5, 2014 at 5:38 PM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > On Tue, Aug 05, 2014 at 11:33:01AM +0800, Ming Lei wrote:
> >> These patches bring up below 4 changes:
> >>         - introduce object allocation pool and apply it to
> >>         virtio-blk dataplane for improving its performance
> >>
> >>         - introduce selective coroutine bypass mechanism
> >>         for improving performance of virtio-blk dataplane with
> >>         raw format image
> >>
> >>         - linux-aio changes: fixing for cases of -EAGAIN and partial
> >>         completion, increase max events to 256, and remove one unuseful
> >>         fields in 'struct qemu_laiocb'
> >>
> >>         - support multi virtqueue for virtio-blk
> >
> > Please split up this patch series into separate patch series.
> >
> > These are independent changes and there is no reason to combine them.
> > You're doing yourself a disservice because changes that are ready to be
> > applied are getting held up by those that still need more discussion.
> 
> Without previous optimization patches, the mq conversion can't
> obtain so much improvement, that is why I put them together.

You can post two sets of numbers: "independent results" and "together
with series X, Y, and Z".

> Also mq conversion depends on linux-aio fix too.

No problem, just include a note in the cover letter for the mq series
stating that this series depends on the linux-aio fix.

Maintainers keep an eye out for that and make sure that the dependencies
are merged before applying.

> Also it becomes a difficult to test these patches if they are splitted,
> and describing the dependency is a bit annoying too.

I understand that you need to manage extra branches and sometimes rebase
between them.  But that's life.

The reason people are pushing back is that you are throwing a blob at
the mailing list and expecting reviewers to dissect it.  Reviewers have
to put more effort in than necessary.  As a result they are scrutinizing
your changes and are not comfortable with them in their current form.

If you want to get patches merged smoothly, split them up and justify
each series with a cover letter and performance results (if it's an
optimization).  That way you get reviewers on your side; they understand
and agree with the benefit of the series.  Make them *want* to merge the
patches.

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]