On 04/04/2012 12:38 PM, Jan Kiszka wrote: > On 2012-04-04 11:36, Avi Kivity wrote: > > On 04/04/2012 12:22 PM, Jan Kiszka wrote: > >>> > >>>>> Until we do have this fast path we can just fill this value with zeros, > >>>>> so kernel patch (almost) does not need to change for this - > >>>>> just the header. > >>>> > >>>> Partially implemented interfaces invite breakage. > >>> > >>> Hmm true. OK scrap this idea then, it's not clear > >>> whether we are going to optimize this anyway. > >>> > >> > >> Also, the problem is that keeping that ID in userspace requires an > >> infrastructure like the MSIRoutingCache that I proposed originally. Not > >> much won /wrt invasiveness there. > > > > Internal qemu refactorings are not a driver for kvm interface changes. > > No, but qemu demonstrates the applicability and handiness of the kernel > interfaces. True. > > > >> So we should really do the routing > >> optimization in the kernel - one day. > > > > No, we need to make a choice: > > > > explicit handles: array lookup, more expensive setup > > no handles: hash loopup, more expensive, but no setup, and no artificial > > limits > > ...and I think we should head for option 2. I'm not so sure anymore. Sorry about the U turn, but remind me why? In the long term it will be slower. -- 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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
