[ovs-dev] [PATCH 1/2] docs: Clarify the superiority of dpdkvhostuserclient

Wed Jun 7 22:49:57 UTC 2017

Darrell Ball <dball at vmware.com> writes:

> On 6/4/17, 9:15 AM, "Aaron Conole" <aconole at redhat.com> wrote:
>
>     Darrell Ball <dball at vmware.com> writes:
>     
>     > On 5/26/17, 7:12 AM, "ovs-dev-bounces at openvswitch.org on behalf of Stephen Finucane" <ovs-dev-bounces at openvswitch.org on behalf of stephen at that.guru> wrote:
>     >
>     >     Apparently dpdkvhostuser interfaces are inferior to dpdkvhostuserclient.
>     >     Explain why.
>     >     
>     >     Signed-off-by: Stephen Finucane <stephen at that.guru>
>     >     Cc: Ciara Loftus <ciara.loftus at intel.com>
>     >     Cc: Kevin Traynor <ktraynor at redhat.com>
>     >     ---
>     >     I'd like to note what happens to traffic when OVS or a VM is restarted
>     >     for both port types. If someone knows the answer to this, please feel
>     >     free to take ownership of that patch/ask me for a v2.
>     >     ---
>     >      Documentation/topics/dpdk/vhost-user.rst | 8 ++++++--
>     >      1 file changed, 6 insertions(+), 2 deletions(-)
>     >     
>     >     diff --git a/Documentation/topics/dpdk/vhost-user.rst b/Documentation/topics/dpdk/vhost-user.rst
>     >     index ba22684..2e2396b 100644
>     >     --- a/Documentation/topics/dpdk/vhost-user.rst
>     >     +++ b/Documentation/topics/dpdk/vhost-user.rst
>     >     @@ -54,8 +54,12 @@ vHost User sockets, and the client connects to the server. Depending on which
>     >      port type you use, ``dpdkvhostuser`` or ``dpdkvhostuserclient``, a different
>     >      configuration of the client-server model is used.
>     >      
>     >     -For vhost-user ports, Open vSwitch acts as the server and QEMU the client.  For
>     >     -vhost-user-client ports, Open vSwitch acts as the client and QEMU the server.
>     >     +For vhost-user ports, Open vSwitch acts as the server and QEMU the client. This
>     >     +means if OVS dies, all VMs **must** be restarted. On the other hand, for
>     >     +vhost-user-client ports, OVS acts as the client and QEMU the server. This means
>     >     +OVS can die and be restarted without issue,
>     >
>     >
>     > “ and it is also possible to restart
>     >     +an instance itself.”
>     >
>     > Restart a VM instance ?; if so, it seems already implied.
>     > Or OVS instance ?
>     >
>     >  For this reason, vhost-user-client ports are the preferred
>     >     +type for most use cases.
>     >
>     > At one point, because I am helping to support OVS-DPDK, I had both
>     > vhostuser and vhostuserclient ports configured on our performance servers,
>     > because I thought I should have both, so I could support both. Then, I realized I
>     > just did not want to use vhostuser ports, due to the permissions/security
>     > issues, noticed on OVS restart.
>     >
>     > So, what are the use cases (besides self-flagellation) for using vhostuser ports in lieu of
>     > vhostuserclient ports ?
>     
>     At the time they were introduced, deployed versions of qemu couldn't
>     support the vhostuserclient mode.  I'm less sure what the state of that
>     world looks like today.  I know that RHEL 7.3 doesn't ship a QEMU that
>     supports client-mode ports.
>
> I understand about the qemu version requirements; I really wanted to make sure
> that there were no specific use cases for server mode, per this patch text.
>
> Do you know if there are any issues with RHEL 7.3 supporting QEMU 2.7 ? 

The current RHEV qemu version is 2.6, so it will have problems.

By the time 7.4 releases the RHEV qemu will at least be 2.9, so it's
probably okay.

>     > If the answer is none, can we deprecate them in OVS 2.8 (update NEWS etc) and
>     > remove them in OVS 2.9 ?
>     
>     I'm all for deprecating them as long as the major vendors (RH, Debian,
>     SUSE) support the newer QEMU.  2.9 may be too aggressive for removal -
>     perhaps the release after?  Just to be sure there is a path to migration
>     for existing users.
>
> Agreed; ideally, qemu should be upgradable to 2.7 on recent versions of
> common/important distros such RHEL/centos, SLES and debian.

Yep.

> Many people have a national holiday today, so let us see when they get back.
>
> If we can deprecate, then:

For these two:

> 1) We might deprecate now and say in an upcoming release, vhostuserserver port code
> will be removed.
> 2) We can add a log warning to that effect on configuration.

Good idea.  I just submitted a patch to do this:

https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/333609.html

> 3) We can add text here to suggest upgrading to qemu 2.7 if at all possible
> and using client mode. qemu 2.9 is out, upgrade to 2.7 should be
> possible in many (most ?) cases, for those
> serious about using ovs-dpdk with VM connectivity.

I'm not sure how the upgrade utility would work, since the location of
the vhostuser socket is important part of this.

>     Maybe I'm off my rocker, though.
>     
>     >      .. _dpdk-vhost-user:
>     >      
>     >     -- 
>     >     2.9.4
>     >     
>     >     _______________________________________________
>     >     dev mailing list
>     >     dev at openvswitch.org
>     >     https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=hjj87k1Hqw8FflJQ7cRgAFD8O4-t89ARPxN1qb1XrZs&s=LCybNvXe55JKD-bmxLDouYfRUdKhk7qHQFv2Wsk7UsA&e= 
>     >     
>     >
>     > _______________________________________________
>     > dev mailing list
>     > dev at openvswitch.org
>     > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=McRcrdQlkt_TY30rKe-4vvoXejvWEZkHpXG9whN4bt8&s=_9m8xG0PLIC2m9gKAjZ2FJKtW7XIRDhVqQmqOtPUgo0&e= 
>     
>
>
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev