Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user.

Hi

On Thu, Mar 18, 2021 at 11:47 PM Ilya Maximets [off-list ref] wrote:

On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:

quoted

On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
Hi,
Some questions to understand the problems that SocketPair Broker solves:

quoted

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.

-- 
Marc-André Lureau