[Libosinfo] [osinfo-db PATCH 1/3] workload: Add high performance

[Daniel P. Berrangé]

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 at redhat.com>
> > ---
> >  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 at redhat.com
> 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 :|