On Sat, Nov 17, 2018 at 01:06:11AM +0100, Martin Kletzander wrote: > This is an example workload that sums up the "common knowledge" that virtio > devices have the best performance. Already today when using libosinfo, a mgmt app will know which devices are "better". ie any application which supports QEMU will always try to use virtio-net, before trying e1000(e), before trying rtl8139, etc. So will query libosinfo to find out which of these devices an OS supports and use the best available. IOW, if a guest supports virtio-XXX an mgmt app will already be enabling them by default. So what value is added by having a workload list these devices, as opposed to what the app will do today when using libosinfo ? Or to put it another way, if the user didn't pick the "high-perf" workload and instead got a different workload that didn't list any devices, what difference would there be to guest config ? If anything following the workload recommendation would be a step backwards because it is KVM specific, not considering the Xen paravirt devices. > As a possible addition it also shows the optimal (let's say) number of I/O > threads to choose. > > Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> > --- > data/workload/example.com/high-perf.xml.in | 38 ++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > create mode 100644 data/workload/example.com/high-perf.xml.in > > diff --git a/data/workload/example.com/high-perf.xml.in b/data/workload/example.com/high-perf.xml.in > new file mode 100644 > index 000000000000..9c3aec7d811e > --- /dev/null > +++ b/data/workload/example.com/high-perf.xml.in > @@ -0,0 +1,38 @@ > +<libosinfo version="0.0.1"> > +<!-- Licensed under the GNU General Public License version 2 or later. > + See http://www.gnu.org/licenses/ for a copy of the license text --> > + <workload id="http://example.com/high-perf";> > + <short-id>high-perf</short-id> > + <_name>High Performance</_name> > + </workload> > + > + <devices> > + <device id="http://pcisig.com/pci/1af4/1052"/> <!-- virtio1.0-input --> > + <device id="http://pcisig.com/pci/1af4/1048"/> <!-- virtio1.0-scsi --> > + <device id="http://pcisig.com/pci/1af4/1044"/> <!-- virtio1.0-rng --> > + <device id="http://pcisig.com/pci/1af4/1042"/> <!-- virtio1.0-block --> > + <device id="http://pcisig.com/pci/1af4/1041"/> <!-- virtio1.0-net --> > + </devices> > + > + <features> > + <!-- > + These can be: > + - just list of strings > + - or list of feature-IDs where feature is a new object that has: > + - description > + - and human explanation of what to set and how > + --> > + <iothreads>yes</iothreads> I wonder if this is too simplistic to really be useful ? I feel like an mgmt app shouldn't need a workload to say iothreads=yes in order to know that using iothreads is a good idea for maximising performance when the guest has > 1 vCPU. IOW there's only really one right answer and that's iothreads=yes > + <!-- > + probably pointless, but someone might want to be able to specify > + something like: > + <iothreads> > + <min> > + <cpus/> > + <number>4</number> > + </min> > + </iothreads> IMHO this starts to be more useful than a simple yes|no, as it is starting to express a concept where there are many possible right answers. More interesting would also be ideas about CPU pinning and sched tuning > + --> > + </features> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
