On Tue, Nov 20, 2018 at 03:44:51PM +0000, Daniel P. Berrangé wrote: > 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 ? Or are these devices supposed to indicate a white list ? ie refuse to install the guest if it doesn't support virtio-blk ? > 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 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
