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
