From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCs33-0006RF-Fk for qemu-devel@nongnu.org; Wed, 28 Mar 2012 08:32:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCs2x-0002Oa-3h for qemu-devel@nongnu.org; Wed, 28 Mar 2012 08:32:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCs2w-0002OJ-Rp for qemu-devel@nongnu.org; Wed, 28 Mar 2012 08:32:15 -0400 Message-ID: <4F7304CA.4080509@redhat.com> Date: Wed, 28 Mar 2012 14:32:10 +0200 From: Avi Kivity MIME-Version: 1.0 References: <865ef757142e5b9a670dfc9bcd8eb0ff7ab5d58b.1332371825.git.jan.kiszka@web.de> <4F72F165.8020009@redhat.com> <4F72F6F5.5020202@siemens.com> <4F72F9A9.6000700@redhat.com> <4F72FC0D.7090005@siemens.com> In-Reply-To: <4F72FC0D.7090005@siemens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 1/2] kvm: Introduce basic MSI support in-kernel irqchips List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Marcelo Tosatti , qemu-devel , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 03/28/2012 01:54 PM, Jan Kiszka wrote: > > > >>> > >>>> interface transparent. We create those routes on demand and keep them > >>>> in a hash table. Succeeding messages can then search for an existing > >>>> route in the table first and reuse it whenever possible. If we should > >>>> run out of limited GSIs, we simply flush the table and rebuild it as > >>>> messages are sent. > >>>> > >>>> This approach is rather simple and could be optimized further. However, > >>>> it is more efficient to enhance the KVM API so that we do not need this > >>>> clumsy dynamic routing over futures kernels. > >>> > >>> Two APIs are clumsier than one. > >> > >> The current one is very clumsy for user-injected MSIs while the new one > >> won't be. It will also be very simple it implement if you recall the > >> patch. I think that is worth it. > > > > Don't see why. The clumsiness will be retained. The cpu doesn't care > > how clumsy the API is, only the reader. > > We won't have to do any hashing/caching over the new API, just a plain > "deliver this MSI" IOCTL. Specifically all our upcoming archs like Power > and ARM will be able to take the shiny highway instead of the winding > countryside road. Upcoming archs are a good card to play. However that code will remain for x86, and there's nothing arch specific about it, is there? > > > >>> wet the patch itself, suggest replacing the home grown hash with > >>> http://developer.gnome.org/glib/2.30/glib-Caches.html. > >> > >> Let's keep it simple :). We have no need for many of those features, and > >> it would not be possible to implement the logic as compact as it is > >> right now. > > > > Due to the callbacks? > > Yep. That API pays of if you have more iterations and insertions/removals. Okay, will wait for std::unordered_map<>. -- error compiling committee.c: too many arguments to function