netdev - Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Dec 2009 22:20:32 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <gregory.haskins@...il.com>
CC:	Andi Kleen <andi@...stfloor.org>, kvm@...r.kernel.org,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	netdev@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Ingo Molnar <mingo@...e.hu>, torvalds@...ux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html