[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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:
    > 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:
    > 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
    > (;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

     \ /
      Last update: 2009-08-17 17:17    [W:0.037 / U:49.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site