netdev - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4B2FAE7B.9030005@codemonkey.ws>
Date:	Mon, 21 Dec 2009 11:20:59 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Gregory Haskins <gregory.haskins@...il.com>
CC:	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

On 12/21/2009 10:46 AM, Gregory Haskins wrote:
> The very best you can hope to achieve is 1:1 EOI per signal (though
> today virtio-pci is even worse than that).  As I indicated above, I can
> eliminate more than 50% of even the EOIs in trivial examples, and even
> more as we scale up the number of devices or the IO load (or both).
>    

If optimizing EOI is the main technical advantage of vbus, then surely 
we could paravirtualize EOI access and get that benefit in KVM without 
introducing a whole new infrastructure, no?

>> This is a
>> light weight exit today and will likely disappear entirely with newer
>> hardware.
>>      
> By that argument, this is all moot.  New hardware will likely obsolete
> the need for venet or virtio-net anyway.

Not at all.  But let's focus on concrete data.  For a given workload, 
how many exits do you see due to EOI?  They should be relatively rare 
because obtaining good receive batching is pretty easy.  Considering 
these are lightweight exits (on the order of 1-2us), you need an awfully 
large amount of interrupts before you get really significant performance 
impact.  You would think NAPI would kick in at this point anyway.

Do you have data demonstrating the advantage of EOI mitigation?

Regards,

Anthony Liguori
--
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