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 E97EDA0562; Fri, 19 Mar 2021 09:52:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7BB70140F33; Fri, 19 Mar 2021 09:52:10 +0100 (CET) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by mails.dpdk.org (Postfix) with ESMTP id 19F43140F2C for ; Fri, 19 Mar 2021 09:52:09 +0100 (CET) Received: by mail-ed1-f51.google.com with SMTP id w18so9872853edc.0 for ; Fri, 19 Mar 2021 01:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2KS55zpgy/ANBEa/O4RElcfuI7UdBgIB+XU2kMkuMSg=; b=fY4luEZh4VQbB5lovHq0re4dFXZ9TGrY+99j3DoeyynytMVQ1wAAJlW1CenRYp63Eu CTMSc7Gbq2LH+HzKsfpRXJKHaoUVue/3/nOhoDKDQdGqO73bY0PVMM9VBkGB7LnLuYe1 guz3ZfRjMd9HvNl5LQ4wEbuols68Vp5Zl2EUuWJYZuL7Dy/MtJDLiEyV1izuxiayXgf0 mPgj+s4zTfuFMK/FHVjPyYk5mtMOgBdCY6HJq/herY0nFYk3KIdi1qPbge0cR7brNvUC QObQyaw2AAelXY+pR47mmbDiuM2HWo11TK5uQIuytboUIC6h/aYOJltVsFSRhGRCELBm Am1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2KS55zpgy/ANBEa/O4RElcfuI7UdBgIB+XU2kMkuMSg=; b=QI+Zapr0XdnTZCNa9V+GJIQsETJ3XksFS365fVei1NIsKDl0RlQXT0Q1mM72PfQN+F kyTggbt9ItVQmRWHk4xzAn78rGbiWY1OOGDQhiuCGXemJdHxCf/9DRFIllEBnGAPnQMU c3Xj73+VFinZIidrH1/mttzP5CycwTkNV0/5dvtE5tl/MearKfnC8fGhFSF2M4Z242bE S/XMl9Bdnyjl+OxKwiaaypJUZJ8fwI9wE91XzDvu3STsgriwft1Cxq0mboCt8tZq8JuK WTe8F3zSXaoCUKksXRIISEeY07pQD/R3hBRUTLvnw92U/b8Ir3EtmJ23kcYdpaJ3gkNV a8vg== X-Gm-Message-State: AOAM530HNy73lPbEZEEuFk46tX4cDlGvVo5KTfjoRmRyNT26Rv5BOGfq eeEReYPxqpFdAqmakkHL2NZCOBkEkaQEDwwtcgM= X-Google-Smtp-Source: ABdhPJxQSfPdvkQSd4NH/v8N7PE3QhRvztwRJ1MsWZZQsDTFGtP2XA1B6kAG+Z/wfXDD24vu12id2AR54FldhDalMoA= X-Received: by 2002:aa7:dbd3:: with SMTP id v19mr8164417edt.314.1616143928769; Fri, 19 Mar 2021 01:52:08 -0700 (PDT) MIME-Version: 1.0 References: <20210317202530.4145673-1-i.maximets@ovn.org> In-Reply-To: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Date: Fri, 19 Mar 2021 12:51:57 +0400 Message-ID: To: Ilya Maximets Cc: Stefan Hajnoczi , Maxime Coquelin , Chenbo Xia , dev@dpdk.org, Adrian Moreno , Julia Suvorova , Daniel Berrange Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" Hi On Thu, Mar 18, 2021 at 11:47 PM Ilya Maximets wrote: > On 3/18/21 6:52 PM, Stefan Hajnoczi wrote: > > 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? > > Hi, Stefan. Thanks for your feedback! > > The idea is to have the SocketPair Broker running right from the > boot of the host. If it will use a systemd socket-based service > activation, the socket should persist while systemd is alive, IIUC. > OOM, crash and restart of the broker should not affect existence > of the socket and systemd will spawn a service if it's not running > for any reason without loosing incoming connections. > > Since the solution relies on systemd, why not use DBus to perform authentication, service discovery and setup the socketpair between peers? You don't need an extra service broker in this case. When the org.foo service shows up, call org.foo.Connect() to return the fd of the client end (or throw an error etc) I don't think establishing socketpair connection between process peers sharing some ID, without any other context, is going to be so useful. The relation is usually not symmetrical, and you usually have associated setup/configuration details. --=20 Marc-Andr=C3=A9 Lureau