lkml.org 
[lkml]   [2009]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
On 08/19/2009 07:27 AM, Gregory Haskins wrote:
>
>> This thread started because i asked you about your technical
>> arguments why we'd want vbus instead of virtio.
>>
> (You mean vbus vs pci, right? virtio works fine, is untouched, and is
> out-of-scope here)
>

I guess he meant venet vs virtio-net. Without venet vbus is currently
userless.

> Right, and I do believe I answered your questions. Do you feel as
> though this was not a satisfactory response?
>

Others and I have shown you its wrong. There's no inherent performance
problem in pci. The vbus approach has inherent problems (the biggest of
which is compatibility, the second managability).

>> Your answer above
>> now basically boils down to: "because I want it so, why dont you
>> leave me alone".
>>
> Well, with all due respect, please do not put words in my mouth. This
> is not what I am saying at all.
>
> What I *am* saying is:
>
> fact: this thread is about linux guest drivers to support vbus
>
> fact: these drivers do not touch kvm code.
>
> fact: these drivers to not force kvm to alter its operation in any way.
>
> fact: these drivers do not alter ABIs that KVM currently supports.
>
> Therefore, all this talk about "abandoning", "supporting", and
> "changing" things in KVM is, premature, irrelevant, and/or, FUD. No one
> proposed such changes, so I am highlighting this fact to bring the
> thread back on topic. That KVM talk is merely a distraction at this
> point in time.
>

s/kvm/kvm stack/. virtio/pci is part of the kvm stack, even if it is
not part of kvm itself. If vbus/venet were to be merged, users and
developers would have to choose one or the other. That's the
fragmentation I'm worried about. And you can prefix that with "fact:"
as well.

>> We all love faster code and better management interfaces and tons
>> of your prior patches got accepted by Avi. This time you didnt even
>> _try_ to improve virtio.
>>
> Im sorry, but you are mistaken:
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/02443.html
>

That does nothing to improve virtio. Existing guests (Linux and
Windows) which support virtio will cease to work if the host moves to
vbus-virtio. Existing hosts (running virtio-pci) won't be able to talk
to newer guests running virtio-vbus. The patch doesn't improve
performance without the entire vbus stack in the host kernel and a
vbus-virtio-net-host host kernel driver.

Perhaps if you posted everything needed to make vbus-virtio work and
perform we could compare that to vhost-net and you'll see another reason
why vhost-net is the better approach.

> You are also wrong to say that I didn't try to avoid creating a
> downstream effort first. I believe the public record of the mailing
> lists will back me up that I tried politely pushing this directly though
> kvm first. It was only after Avi recently informed me that they would
> be building their own version of an in-kernel backend in lieu of working
> with me to adapt vbus to their needs that I decided to put my own
> project together.
>

There's no way we can adapt vbus to our needs. Don't you think we'd
preferred it rather than writing our own? the current virtio-net issues
are hurting us.

Our needs are compatibility, performance, and managability. vbus fails
all three, your impressive venet numbers notwithstanding.

> What should I have done otherwise, in your opinion?
>

You could come up with uses where vbus truly is superior to
virtio/pci/whatever (not words about etch constraints). Showing some of
those non-virt uses, for example. The fact that your only user
duplicates existing functionality doesn't help.


>> And fragmentation matters quite a bit. To Linux users, developers,
>> administrators, packagers it's a big deal whether two overlapping
>> pieces of functionality for the same thing exist within the same
>> kernel.
>>
> So the only thing that could be construed as overlapping here is venet
> vs virtio-net. If I dropped the contentious venet and focused on making
> a virtio-net backend that we can all re-use, do you see that as a path
> of compromise here?
>

That's a step in the right direction.

>> I certainly dont want that. Instead we (at great expense and work)
>> try to reach the best technical solution.
>>
> This is all I want, as well.
>

Note whenever I mention migration, large guests, or Windows you say
these are not your design requirements. The best technical solution
will have to consider those.

>> If the community wants this then why cannot you convince one of the
>> most prominent representatives of that community, the KVM
>> developers?
>>
> Its a chicken and egg at times. Perhaps the KVM developers do not have
> the motivation or time to properly consider such a proposal _until_ the
> community presents its demand.

I've spent quite a lot of time arguing with you, no doubt influenced by
the fact that you can write a lot faster than I can read.

>> Furthermore, 99% of your work is KVM
>>
> Actually, no. Almost none of it is. I think there are about 2-3
> patches in the series that touch KVM, the rest are all original (and
> primarily stand-alone code). AlacrityVM is the application of kvm and
> vbus (and, of course, Linux) together as a complete unit, but I do not
> try to hide this relationship.
>
> By your argument, KVM is 99% QEMU+Linux. ;)
>

That's one of the kvm strong points...

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.



\
 
 \ /
  Last update: 2009-08-19 07:25    [W:0.258 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site