From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 6198AA0A0B;
Mon, 1 Feb 2021 14:42:52 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id DFF5C40693;
Mon, 1 Feb 2021 14:42:51 +0100 (CET)
Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230])
by mails.dpdk.org (Postfix) with ESMTP id 92F1340687
for <dev@dpdk.org>; Mon, 1 Feb 2021 14:42:50 +0100 (CET)
Received: from [192.168.1.23] (ip-78-45-89-65.net.upcbroadband.cz
[78.45.89.65]) (Authenticated sender: i.maximets@ovn.org)
by relay10.mail.gandi.net (Postfix) with ESMTPSA id 2B3CE240008;
Mon, 1 Feb 2021 13:42:47 +0000 (UTC)
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
Ilya Maximets <i.maximets@ovn.org>, dev@dpdk.org, chenbo.xia@intel.com,
olivier.matz@6wind.com, amorenoz@redhat.com, david.marchand@redhat.com,
Ian Stokes <ian.stokes@intel.com>, Kevin Traynor <ktraynor@redhat.com>,
Flavio Leitner <fbl@sysclose.org>
Cc: ovs-dev <ovs-dev@openvswitch.org>
References: <20210126101639.250481-1-maxime.coquelin@redhat.com>
<971e37fb-3889-ee94-c45c-e05f51b036ba@ovn.org>
<5379d25e-e33f-4dae-f53b-b57c00da3d64@ovn.org>
<47b6ea0d-0f8d-e569-c2ae-009782e4dfc9@redhat.com>
From: Ilya Maximets <i.maximets@ovn.org>
Message-ID: <29242f3d-ea42-8977-2ea8-de8a54e165a1@ovn.org>
Date: Mon, 1 Feb 2021 14:42:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <47b6ea0d-0f8d-e569-c2ae-009782e4dfc9@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On 2/1/21 2:16 PM, Maxime Coquelin wrote:
> Hi Ilya,
>
> On 2/1/21 2:03 PM, Ilya Maximets wrote:
>> CC: ovs-dev
>>
>> On 2/1/21 2:00 PM, Ilya Maximets wrote:
>>> On 1/26/21 11:15 AM, Maxime Coquelin wrote:
>>>>
>>>> Only functionnal change in this second part is making the
>>>> Vhost-user server mode blocking at init time, as long as
>>>> a client is not connected. The goal of this change is to
>>>> make the Vhost-user support much more robust, as without
>>>> blocking, the driver has to assume features that are going
>>>> to be supported by the client, which is very fragile and
>>>> error prone. As a side-effect, it also simplifies the
>>>> logic nin several place of the virtio-user PMD.
>>>
>>> Hi, Maxime.
>>>
>>> I didn't actually look at the code, but I have a question.
>>> Does above text mean that with this change OVS will hang inside
>>> driver_register() or similar function until client is connected
>>> to dpdkvhostuser (server mode) port?
>>>
>>> If so, I think, we will not be able to support server mode
>>> in OVS anymore and will have to actually remove it. It's
>>> deprecated for a long time now, but I think it might still be in
>>> use by some people, especially for virtio-user usecase.
>
> No, there is no impact for OVS. My explanation was maybe a bit
> confusion, sorry about that.
>
> I meant that Virtio-user PMD, acting as Vhost-user master in server
> mode, will be blocking waiting for client (OVS dpdkvhostuserclient in
> your case) connection. This makes the Virtio-user PMD in server mode to
> behave the same as QEMU Vhost-user port in server mode.
Oh. OK. So the only affected party is 'net_virtio_user' PMD and vhost
library is not affected, right?
And in this case the following command will block OVS:
ovs-vsctl add-port br0 vu -- set Interface vu type=dpdk \
options:dpdk-devargs="net_virtio_user,path=vu.sock,server=1"
Is that correct?
(I'm not sure if this works right now, though. I didn't test it.)
>
> Only noticeable effect on OVS side should be more reliability, as
> without this change, Virtio-user PMD could assume OVS Vhost-user backend
> would support features before the connection happens.
>
>>> Best regards, Ilya Maximets.
>>>
>>
>
> Regards,
> Maxime
>