On 3/19/21 5:11 PM, Ilya Maximets wrote: > On 3/19/21 3:39 PM, Stefan Hajnoczi wrote: >> Hi Ilya, >> By the way, it's not clear to me why dpdkvhostuser is deprecated. If OVS >> is restarted then existing vhost-user connections drop with an error but >> QEMU could attempt to reconnect to the UNIX domain socket which the new >> OVS instance will set up. >> >> Why is it impossible to reconnect when OVS owns the listen socket? > > Well, AFAIK, qemu reconnects client connections only: > > ``reconnect`` sets the timeout for reconnecting on non-server > sockets when the remote end goes away. qemu will delay this many > seconds and then attempt to reconnect. Zero disables reconnecting, > and is the default. > > I'm not sure about exact reason. It was historically this way. > For me it doesn't make much sense. I mean, your right that it's > just a socket, so it should not matter who listens and who connects. > If reconnection is possible in one direction, it should be possible > in the opposite direction too.
Sorry, my thought slipped. :) Yes, QEMU supports re-connection for client sockets. So, in theory, dpdkvhostuser ports should work after re-connection. And that would be nice. I don't remember right now why this doesn't work... Maybe vhost-user parts in QEMU doesn't handle this case. Need to dig some more into that and refresh my memory. It was so long ago... Maxime, do you remember? > > dpdkvhostuser was deprecated just to scare users and force them to > migrate to dpdkvhostuserclient and avoid constant bug reports like: > > "OVS service restarted and network is lost now". > > BTW, virtio-user ports in DPDK doesn't support re-connection in client > mode too. This is still true, though. virtio-user in client mode doesn't reconnect. > > BTW2, with SocketPair Broker it might be cheaper to implement server > reconnection in QEMU because all connections in these case are client > connections, i.e. both ends will connect() to a broker. > > Bets regards, Ilya Maximets. >
