From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> 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 <dev@dpdk.org>; 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 <i.maximets@ovn.org>, Stefan Hajnoczi <stefanha@redhat.com> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>, Chenbo Xia <chenbo.xia@intel.com>, dev@dpdk.org, Adrian Moreno <amorenoz@redhat.com>, Julia Suvorova <jusual@redhat.com> References: <20210317202530.4145673-1-i.maximets@ovn.org> <YFS3j3QFsF7X+jlY@stefanha-x1.localdomain> <ee5e0d95-1684-c283-c48c-c45cc2bec57b@ovn.org> From: Ilya Maximets <i.maximets@ovn.org> 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: <ee5e0d95-1684-c283-c48c-c45cc2bec57b@ovn.org> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 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. >