Messages in this thread | | | Date | Mon, 17 Aug 2009 18:13:25 +0300 | From | Avi Kivity <> | Subject | Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects |
| |
On 08/17/2009 06:05 PM, Gregory Haskins wrote: > Hi Ingo, > > 1) First off, let me state that I have made every effort to propose this > as a solution to integrate with KVM, the most recent of which is April: > > http://lkml.org/lkml/2009/4/21/408 > > If you read through the various vbus related threads on LKML/KVM posted > this year, I think you will see that I made numerous polite offerings to > work with people on finding a common solution here, including Michael. > > In the end, Michael decided that go a different route using some of the > ideas proposed in vbus + venet-tap to create vhost-net. This is fine, > and I respect his decision. But do not try to pin "fracturing" on me, > because I tried everything to avoid it. :) >
Given your post, there are only three possible ways to continue kvm guest driver development:
- develop virtio/vhost, drop vbus/venet - develop vbus/venet, drop virtio - develop both
Developing both fractures the community. Dropping virtio invalidates the installed base and Windows effort. There were no strong technical reasons shown in favor of the remaining option.
> Since I still disagree with the fundamental approach of how KVM IO > works,
What's that?
> Prior to my effort, KVM was humming along at the status quo and I came > along with a closer eye and almost doubled the throughput and cut > latency by 78%. Given an apparent disagreement with aspects of my > approach, Michael went off and created a counter example that was > motivated by my performance findings. >
Oh, virtio-net performance was a thorn in our side for a long time. I agree that venet was an additional spur.
> Therefore, even if Avi ultimately accepts Michaels vhost approach > instead of mine, Linux as a hypervisor platform has been significantly > _improved_ by a little friendly competition, not somehow damaged by it. >
Certainly, and irqfd/ioeventfd are a net win in any case.
> 4) Lastly, these patches are almost entirely just stand alone Linux > drivers that do not affect KVM if KVM doesn't wish to acknowledge them. > Its just like any of the other numerous drivers that are accepted > upstream into Linux every day. The only maintained subsystem that is > technically touched by this series is netdev, and David Miller already > approved of the relevant patch's inclusion: > > http://lkml.org/lkml/2009/8/3/505 > > So with all due respect, where is the problem? The patches are all > professionally developed according to the Linux coding standards, pass > checkpatch, are GPL'ed, and work with a freely available platform which > you can download today > (http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=summary) >
As I mentioned before, I have no technical objections to the patches, I just wish the effort could be concentrated in one direction.
-- error compiling committee.c: too many arguments to function
| |