From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 010D8A0524; Fri, 19 Mar 2021 17:45:50 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 73A88140FF7; Fri, 19 Mar 2021 17:45:50 +0100 (CET) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by mails.dpdk.org (Postfix) with ESMTP id D3E7F40143 for ; Fri, 19 Mar 2021 17:45:48 +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 EF425240009; Fri, 19 Mar 2021 16:45:46 +0000 (UTC) To: Ilya Maximets , Stefan Hajnoczi Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova References: <20210317202530.4145673-1-i.maximets@ovn.org> From: Ilya Maximets Message-ID: <4f26e9a9-8dd1-f619-4337-dcecf35d9f3b@ovn.org> Date: Fri, 19 Mar 2021 17:45:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. >