On Wed, May 04, 2016 at 08:44:37PM -0700, Yuanhan Liu wrote: > Hello, > > On Wed, May 04, 2016 at 10:13:49PM +0300, Michael S. Tsirkin wrote: > > How do you avoid it? > > > > > > Management is required to make this robust, auto-reconnect > > > > is handy for people bypassing management. > > > > > > tbh, I don't like autoreconnect. My previous series didn't include > > > this and assumed the feature would be supported only when qemu is > > > configured to be the server. I added reconnect upon request by users. > > > > I don't have better solutions so OK I guess. > > Yes, it's a request from me :) > Well, there may be few others also requested that. > > The reason I had this asking is that, so far, we just have only one > vhost-user frontend, and that is QEMU. But we may have many backends, > I'm aware of 4 at the time writing, including the vubr from QEMU. > While we could do vhost-user client and reconnect implementation > on all backends, it's clear that implementing it in the only backend > (QEMU) introduces more benefits. > > OTOH, I could implement DPDK vhost-user as client and try reconnect > there, if that could makes all stuff a bit easier. > > --yliu
In my opinion, if slave initiates disconnecting then slave should also initiate connecting. In a sense, autoretry of connections is not a vhost-user feature. It's a general chardev feature. It also does not have to be related to disconnect: retrying on first connect failure makes exactly as much sense. -- MST
