Re: [libvirt] [PATCH v2] Add support for virtio-net.tx_queue_size

On 07/18/2017 07:12 AM, Michal Privoznik wrote: Beyond that, that same statement (or something nearly identical) is repeated in multiple places throughout the XML documentation. There are at least two classes of these attributes that I can think of: 1) attributes that are automatically set to a sane value by libvirt when not specified (and they usually *aren't* specified), and saved in the config XML in order to assure they are set the same every time the domain is started (to preserve guest ABI). These are intended to record whatever was the default setting for the attribute at the time the domain was created. For example, a pcie-root-port controller might have <model name='ioh3420'/> set, if that was the only type of pcie-root-port available at the time a domain was created; this comes in handy now that there is a generic pcie-root-port (which also has <model name='pcie-root-port'/>) - existing domains don't get their ABI screwed up when they're migrated to a newer host. 2) knobs that have been added in over the years at the request/demand from below (qemu) and above (ovirt / openstack), many of them obscure, difficult to explain with any amount of useful detail, and almost never worthy of being manually set (and if you "don't know what you're doing", you're just as likely to make things worse as to make them better). tx_queue_size is one of the latter. For either of these types of attributes, they need to be documented so that someone encountering them (or actively searching them out) will at least have a basic idea what the attribute is named / used for, but we also need to warn the casual user to not mess with them. I don't see anything ridiculous about that. I think it's a bit too much burden on libvirt to expect that much detail to be included in formatdomain.html. Heck, I don't know if anyone even *knows* that much detail right now. I disagree. The setting is documented so that people can know that it exists. Anyone *really* interested in performance can look up information about it directly from the source and/or run their own performance tests. My understanding is that's what's done with settings like this, not just in libvirt and qemu, but in the Linux kernel too - people like Red Hat's performance testing groups will run a bunch of benchmark tests with different loads, comparing the test results with different settings of the tuning attributes, and publish white papers with recommendations for settings based on what loads a customer will be running on their systems (over time, these performance tests may discover that one particular setting is the best in *all* conditions, and in that case either qemu or libvirt can begin setting that as the default). But it's impractical to expect the person adding the knob to perform such performance testing and document the proper setting for the knob before it's even been pushed upstream. Instead, we add the knobs and let the perf testing teams know about them, then they run their barrage of tests and tell everyone what (if anything) to do with those knobs. I think the documentation Peter is looking for will come later, from someone else.