[ovs-dev] [dpdk-dev] [PATCH v4 00/44] net/virtio: Virtio PMD rework

Maxime Coquelin maxime.coquelin at redhat.com
Mon Feb 1 13:16:23 UTC 2021


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.

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



More information about the dev mailing list