On 07/17/2017 07:39 AM, Peter Krempa wrote: > On Mon, Jul 17, 2017 at 07:27:24 -0400, sferdjao@xxxxxxxxxx wrote: >> From: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@xxxxxxxxxx> >> >> In version 2.7.0, QEMU introduced support of busy polling for >> vhost-net [0]. To avoid paraphrasing original authors of that feature >> and the purpose it I prefer to share a pointer [1]. >> >> This patch serie exposes throught the NIC driver-specific element a >> new option 'poll_us'. That option is only available with the backend >> driver 'vhost' and that because libvirt automatically fallback to QEMU >> if the driver is not specified where that option is not available. >> >> The option 'poll_us' takes a positive. 0 means that the option >> is not going to be exposed. > We had a similar attempt to do this for disk polling, but that was > rejected since it's not very straightforward for the users to tune this > variable. I think this falls into the same category. > > Here's the discussion for iothread polling: > > https://www.redhat.com/archives/libvir-list/2017-February/msg01048.html The problem is there are already many similar driver-specific odd/not-straightforward tuning parameters present in the XML, so it's difficult to see where to draw the line. I think this may be due to the fact that now whenever a new option is added to qemu, a bugzilla record is semi-automatically opened (by a human, but they almost always do it) requesting libvirt to support that new option, and libvirt developers like to be accommodating (and while some reviews/reviewers base the conversation on "should we even do this?", many/most are simply based on "assuming we want to do this, is this a proper way to do it?", or even "assuming we want to do this, and this is the proper way to do it, has all allocated memory been freed, and error conditions handled?" (e.g. my own review of V1 of these patches :-P). In one of the followups to the iothread polling above, Stefan pointed out a way to accomplish the tuning via qemu commandline passthrough, using qemu's "-set" commandline argument. If libvirt doesn't add support for this attribute in the XML, that's how it will need to be set if someone requires it. And it *is* possible to set poll-us for an interface in this way, e.g.: <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='netdev.hostnet1.poll-us=20'/> </qemu:commandline> which results in this addition to the commandline: -set netdev.hostnet1.poll-us=20 As long as the commandline generated for the interface was something like this: -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=32 everything will work out properly. There are 3 issues with this though: 1) it depends on the specific interface you want to control having the id ("alias" in libvirt-speak) "hostnet0". If the config is modified to add/remove any interfaces prior to this one in the config, the alias will change, and the qemu:commandline will silently begin modifying the wrong interface. (although we've discussed it, I think it is still not possible to explicitly set the alias for a device - they are always automatically determined when the domain is started / device is hotplugged) 2) libvirt documentation explicitly says that use of <qemu:commandline> is not supported, and any use of it will taint the domain config. This means that nobody will be able to use it in a supported commercial setting. .... Well, I forget what the 3rd reason was, but it was a *good* one, and it made a lot of sense 3 days ago when I started writing this message :-P. Oh, wait, now I remember: 3) It's not possible to set options using <qemu:commandline> when hotplugging a device, so the functionality would only be available for interfaces that were present when the domain was started. Anyway, I'm sympathetic to the sentiment of "don't add frivolous new knobs to libvirt config just because someone asked for it and it's easy to do". I've made that same argument before myself. I just think that if we're going to be restrictive like that, we need to be consistent about it, and need to have a story for how to accommodate the request for the functionality in a different way that doesn't have limited functionality, and doesn't render the software unsupportable. I think that in this case none of those is true. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
