dpdk: vhost/virtio staging/testing tree

dpdk: vhost/virtio staging/testing tree

[Victor Kaplansky]

Hi!
Since I was maintaining an internal tree with patches related to
vhost/virtio, I decided to make this staging tree public. It is
useful to me and I hope it will be useful to others.

Collecting patches like this allows tracking dependencies between
patches, their improvement etc. I also rebase the tree so
contributors don't have to.

Before publishing, I test the tree so it can serve as a known
good state for people interested in preliminary testing of
patches that aren't yet upstream, improving testing/validation as
multiple people can test the same code.

Others can send patches referring to that tree to avoid conflicts
when several people are working on the same file.

I can also ping them collectively, keeping and rebasing the
patches that have been posted on list already, so it should be
enough to repost a short summary here, rather than flood
everyone's mailboxes by pinging each patch or reposting a full
patch-set.
 
I would like to stress that this is a staging/testing tree and
not fork of any kind: in particular, don't use this in
production, wait for patches to land upstream first!

If virtio maintainers would like to take over maintaining this
tree, please let me know.

The tree is here:
    git://github.com/vkaplans/dpdk.git virtio

(Could be at dpdk.org just as well, but I don't have an account
 there).

Beware: do not publish a tree on top of this one as I might be
re-basing it.

If you want me to add a patch there, just mail it to the list and
(preferably) Cc me. Also, please let me know if there are more
vhost/virtio related patches that I missed worth includng into my
tree.

---

Here is the list of patches in my tree: they have been tested by
me and are known to work together:

18e570dc vhost: remove duplicate header include
bc5a6193 vhost: enable log_shmfd protocol feature
905161a5 vhost: handle VHOST_USER_SEND_RARP request
99373fac vhost: claim that we support GUEST_ANNOUNCE feature
7cabbc72 vhost: log vring desc buffer changes
978cf176 vhost: log used vring changes
21d371b3 vhost: introduce vhost_log_write
c71eb45d vhost: handle VHOST_USER_SET_LOG_BASE request

4024209f vhost: Add VHOST PMD
6e2f1457 ethdev: Add a new event type to notify a queue state changed event

Thanks,

--
Victor

Re: dpdk: vhost/virtio staging/testing tree

[Yuanhan Liu]

On Fri, Feb 12, 2016 at 01:54:21PM +0200, Victor Kaplansky wrote:
> Hi!

Hi Victor,

> Since I was maintaining an internal tree with patches related to
> vhost/virtio, I decided to make this staging tree public. It is
> useful to me and I hope it will be useful to others.
> 
> Collecting patches like this allows tracking dependencies between
> patches, their improvement etc. I also rebase the tree so
> contributors don't have to.

I had same thoughts, before, aiming to speed the patch review and
merge process.

DPDK community, likely, has a culture of very slow patch review and
merge process: I often saw patches not get reviewed for weeks, even
months! I also saw that a patch has been ACK-ed, but not get merged
until few weeks has been passed. While I am inside the team, I
understand it's a very reasonable phenomenon: every one of us has
lots of tasks to do, and we intend to do the review after all tasks
have been finished.

Despite the fact, I was thinking that I could maintain a tree, so
that I could apply all virtio/vhost patches that has been ACKed in
the first time. Later, I will send pull request to Thomas, from
time to time. Thomas, on the other hand, only need to have a double
check of the patches from my request. If he has any concerns on
some specific patch (or patch set), I will drop them, and let the
author to send a new version.

Put simply, it's a similar style Linux kernel (and QEMU) takes.

Another thing worthy noting is that Bruce started to maintain
a such tree recently:

    http://dpdk.org/browse/next/dpdk-next-net/

So, as long as Bruce merges patches quickly, it should not matter.

> Before publishing, I test the tree so it can serve as a known
> good state for people interested in preliminary testing of
> patches that aren't yet upstream, improving testing/validation as
> multiple people can test the same code.

I was thinking to build a very rough and simple test bot to
achieve that; however, no time for that.

	--yliu