On 12/09/2016 03:42 PM, Daniel P. Berrange wrote:
On Fri, Dec 09, 2016 at 02:35:58PM +0100, Maxime Coquelin wrote:
++Daniel for libvirt
On 11/24/2016 07:31 AM, Yuanhan Liu wrote:
As version here is an opaque string for libvirt and qemu,
anything can be used - but I suggest either a list
of values defining the interface, e.g.
any_layout=on,max_ring=256
or a version including the name and vendor of the backend,
e.g. "org.dpdk.v4.5.6".
The version scheme may not be ideal here. Assume a QEMU is supposed
to work with a specific DPDK version, however, user may disable some
newer features through qemu command line, that it also could work with
an elder DPDK version. Using the version scheme will not allow us doing
such migration to an elder DPDK version. The MTU is a lively example
here? (when MTU feature is provided by QEMU but is actually disabled
by user, that it could also work with an elder DPDK without MTU support).
--yliu
OK, so does a list of values look better to you then?
Yes, if there are no better way.
And I think it may be better to not list all those features, literally.
But instead, using the number should be better, say, features=0xdeadbeef.
Listing the feature names means we have to come to an agreement in all
components involved here (QEMU, libvirt, DPDK, VPP, and maybe more
backends), that we have to use the exact same feature names. Though it
may not be a big deal, it lacks some flexibility.
A feature bits will not have this issue.
I initially thought having key/value pairs would be more flexible, and
could allow migrating to another application if compatible (i.e. from
OVS to VPP, and vice versa...) without needing synchronization between
the applications.
But Daniel pointed me out that it would add a lot of complexity on
management tool side, as it would need to know how to interpret these
key/value pairs. I think his argument is very valid.
So maybe the best way would be the version string, letting the
application (OVS-DPDK/VPP/...) specify which version it is
compatible with.
For the downsides, as soon as a new feature is supported in vhost-user
application, the new version will not be advertised as compatible with
the previous one, even if the user disables the feature in Qemu (as
pointed out by Yuanhan).
We need two distinct capabilities in order to make this work properly.
First, libvirt needs to be able to query the list of (one or more)
supported versions strings for a given host.
Shouldn't be the role of OpenStack/Neutron? IIUC, libvirt knows nothing
about OVS.
Second, when launching QEMU we need to be able to specify the desired
version against the NIC backend.
So, consider host A, initially supporting "ovsdpdk-v1". When libvirt
launches the VM it will specify 'ovsdpgk-v1' as the desired version
string to use.
Now some time later you add features X, Y & Z to a new release of
DPDK and install this on host B. Host B is able to support two
versions 'ovsdppk-v1' and 'ovsdpdk-v2'. When libvirt launches
a VM on host B, it'll pick 'ovsdpgk-v2' by default, since that's
the newest. When libvirt migrates a VM from host A, however,
it will request the old version 'ovsdpdk-v1' in order to ensure
compatibility. Similarly when launching a new VM on host B,
libvirt could choose to use 'ovsdpdk-v1' as the version, in
order to enable migration to the olver host A, if desired.
This is exactly the way QEMU machine types work, hiding the
existance of 100's low level settings / default values, that
a mgmt app would otherwise have to worry about.
I agree on the principle. I need to check what is missing for OVS to
support different versions on different vhost-user ports.
Thanks,
Maxime
Regards,
Daniel
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
