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 2F702A0561; Thu, 18 Mar 2021 18:52:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AC8FE40698; Thu, 18 Mar 2021 18:52:36 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 9B8BC4067C for ; Thu, 18 Mar 2021 18:52:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616089954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BpNv8UPRjh861tema0zH6UiX2SjiGWuStdqjIeLG6JI=; b=h5l1DV6jcvVDrzD4QX8uvvMCP24vbFwZ4+qx3UvOLIFLBXFcFosxf3yRChDnnmBzv/ILLN efT4Brs1K9zLXJhb6C0LC5/sr0wEMy1ax0MNzZGdPJAC4+3F2a3q+yla9U2Jtcm7lJZIpv 2IaTz6T6o/59502eQq8l5HQB55DA0QA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-236-Wu71Aw91ONOnn_su5rV0QQ-1; Thu, 18 Mar 2021 13:52:31 -0400 X-MC-Unique: Wu71Aw91ONOnn_su5rV0QQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0DB2BA0CA0; Thu, 18 Mar 2021 17:52:30 +0000 (UTC) Received: from localhost (ovpn-115-62.ams2.redhat.com [10.36.115.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id 480FF1A38C; Thu, 18 Mar 2021 17:52:19 +0000 (UTC) Date: Thu, 18 Mar 2021 17:52:19 +0000 From: Stefan Hajnoczi To: Ilya Maximets Cc: Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , Daniel Berrange Message-ID: References: <20210317202530.4145673-1-i.maximets@ovn.org> MIME-Version: 1.0 In-Reply-To: <20210317202530.4145673-1-i.maximets@ovn.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=stefanha@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TFMEYKIpd9oKB82k" Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --TFMEYKIpd9oKB82k Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote: Hi, Some questions to understand the problems that SocketPair Broker solves: > Even more configuration tricks required in order to share some sockets > between different containers and not only with the host, e.g. to > create service chains. How does SocketPair Broker solve this? I guess the idea is that SocketPair Broker must be started before other containers. That way applications don't need to sleep and reconnect when a socket isn't available yet. On the other hand, the SocketPair Broker might be unavailable (OOM killer, crash, etc), so applications still need to sleep and reconnect to the broker itself. I'm not sure the problem has actually been solved unless there is a reason why the broker is always guaranteed to be available? > And some housekeeping usually required for applications in case the > socket server terminated abnormally and socket files left on a file > system: > "failed to bind to vhu: Address already in use; remove it and try again" QEMU avoids this by unlinking before binding. The drawback is that users might accidentally hijack an existing listen socket, but that can be solved with a pidfile. > Additionally, all applications (system and user's!) should follow > naming conventions and place socket files in particular location on a > file system to make things work. Does SocketPair Broker solve this? Applications now need to use a naming convention for keys, so it seems like this issue has not been eliminated. > This patch-set aims to eliminate most of the inconveniences by > leveraging an infrastructure service provided by a SocketPair Broker. I don't understand yet why this is useful for vhost-user, where the creation of the vhost-user device backend and its use by a VMM are closely managed by one piece of software: 1. Unlink the socket path. 2. Create, bind, and listen on the socket path. 3. Instantiate the vhost-user device backend (e.g. talk to DPDK/SPDK RPC, spawn a process, etc) and pass in the listen fd. 4. In the meantime the VMM can open the socket path and call connect(2). As soon as the vhost-user device backend calls accept(2) the connection will proceed (there is no need for sleeping). This approach works across containers without a broker. BTW what is the security model of the broker? Unlike pathname UNIX domain sockets there is no ownership permission check. Stefan --TFMEYKIpd9oKB82k--