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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
