From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758954Ab2GLJfy (ORCPT ); Thu, 12 Jul 2012 05:35:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64503 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753453Ab2GLJfx (ORCPT ); Thu, 12 Jul 2012 05:35:53 -0400 Message-ID: <4FFE9A6F.3080607@redhat.com> Date: Thu, 12 Jul 2012 12:35:43 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Alex Williamson CC: Jan Kiszka , "mst@redhat.com" , "gleb@redhat.com" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 0/2] kvm: level irqfd and new eoifd References: <20120703191106.6735.78272.stgit@bling.home> <4FFD4D0A.2000202@redhat.com> <4FFD52E7.3030806@siemens.com> <4FFD5A2B.2040605@redhat.com> <4FFD6221.1060304@siemens.com> <4FFD68C3.7000504@redhat.com> <1342036673.2229.17.camel@bling.home> In-Reply-To: <1342036673.2229.17.camel@bling.home> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/11/2012 10:57 PM, Alex Williamson wrote: >> >> > We still have classic KVM device assignment to provide fast-path INTx. >> > But if we want to replace it midterm, I think it's necessary for VFIO to >> > be able to provide such a path as well. >> >> I would like VFIO to have no regressions vs. kvm device assignment, >> except perhaps in uncommon corner cases. So I agree. > > I ran a few TCP_RR netperf tests forcing a 1Gb tg3 nic to use INTx. > Without irqchip support vfio gets a bit more than 60% of KVM device > assignment. That's a little bit of an unfair comparison since it's more > than just the I/O path. With the proposed interfaces here, enabling > irqchip, vfio is within 10% of KVM device assignment for INTx. For MSI, > I can actually make vfio come out more than 30% better than KVM device > assignment if I send the eventfd from the hard irq handler. Using a > threaded handler as the code currently does, vfio is still behind KVM. > It's hard to beat a direct call chain. We can have a direct call chain with vfio too, using a custom eventfd poll function, no? Assuming we set up a fast path for unicast msi. > For more devices, one that seems common among the non-enterprise users > are TV capture cards, like the old PVR-250/350 devices. These don't > support MSI. Thanks, That doesn't mean they require an interrupt rate that warrants a fast path. But I guess that some combination of old guests or old hardware will want it. -- error compiling committee.c: too many arguments to function