(Sorry for top post...on a mobile) When someone repeatedly makes a claim you believe to be wrong and you correct them, you start to wonder if that person has a less than honorable agenda. In any case, I overreacted. For that, I apologize. That said, you are still incorrect. With what I proposed, the model will run as an in-kernel vbus device, and no longer run in userspace. It would therefore improve virtio-net as I stated, much in the same way vhost-net or venet-tap do today. FYI I am about to log out for the long holiday, so will be unresponsive for a bit. Kind Regards, -Greg On 12/23/09, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 12/23/2009 08:15 PM, Gregory Haskins wrote: >> On 12/23/09 5:22 AM, Avi Kivity wrote: >> >> >>> There was no attempt by Gregory to improve virtio-net. >>> >> If you truly do not understand why your statement is utterly wrong at >> this point in the discussion, I feel sorry for you. If you are trying >> to be purposely disingenuous, you should be ashamed of yourself. In any >> case, your statement is demonstrably bogus, but you should already know >> this given that we talked about at least several times. >> > > There's no need to feel sorry for me, thanks. There's no reason for me > to be ashamed, either. And there's no need to take the discussion to > personal levels. Please keep it technical. > > >> To refresh your memory: http://patchwork.kernel.org/patch/17428/ >> > > This is not an attempt to improve virtio-net, it's an attempt to push > vbus. With this, virtio-net doesn't become any faster, since the > greatest bottleneck is not removed, it remains in userspace. > > If you wanted to improve virtio-net, you would port venet-host to the > virtio-net guest/host interface, and port any secret sauce in > venet(-guest) to virtio-net. After that we could judge what vbus' > contribution to the equation is. > >> In case its not blatantly clear, which I would hope it would be to >> anyone that understands the problem space: What that patch would do is >> allow an unmodified virtio-net to bridge to a vbus based virtio-net >> backend. (Also note that this predates vhost-net by months (the date in >> that thread is 4/9/2009) in case you are next going to try to argue that >> it does nothing over vhost-net). >> > > Without the backend, it is useless. It demonstrates vbus' flexibility > quite well, but does nothing for virtio-net or its users, at least > without a lot more work. > >> This would mean that virtio-net would gain most of the benefits I have >> been advocating (fewer exits, cheaper exits, concurrent execution, etc). >> So this would very much improve virtio-net indeed, given how poorly the >> current backend was performing. I tried to convince the team to help me >> build it out to completion on multiple occasions, but that request was >> answered with "sorry, we are doing our own thing instead". You can say >> that you didn't like my approach, since that is a subjective opinion. >> But to say that I didn't attempt to improve it is a flat out wrong, and >> I do not appreciate it. >> > > Cutting down on the rhetoric is more important than cutting down exits > at this point in time. > > -- > I have a truly marvellous patch that fixes the bug which this > signature is too narrow to contain. > > -- Sent from my mobile device -- 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
