From: Stefano Brivio <sbrivio@redhat.com>
To: Ralph Schmieder <ralph.schmieder@gmail.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: socket.c added support for unix domain socket datagram transport
Date: Fri, 23 Apr 2021 17:29:40 +0200 [thread overview]
Message-ID: <20210423172940.14f48b49@elisabeth> (raw)
In-Reply-To: <1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com>
Hi Ralph,
On Fri, 23 Apr 2021 08:56:48 +0200
Ralph Schmieder <ralph.schmieder@gmail.com> wrote:
> Hey... new to this list. I was looking for a way to use Unix domain
> sockets as a network transport between local VMs.
>
> I'm part of a team where we run dozens if not hundreds of VMs on a
> single compute instance which are highly interconnected.
>
> In the current implementation, I use UDP sockets (e.g. something like
>
> -netdev
> id=bla,type=socket,udp=localhost:1234,localaddr=localhost:5678)
>
> which works great.
>
> The downside of this approach is that I need to keep track of all the
> UDP ports in use and that there's a potential for clashes. Clearly,
> having Unix domain sockets where I could store the sockets in the
> VM's directory would be much easier to manage.
>
> However, even though there is some AF_UNIX support in net/socket.c,
> it's
>
> - not configurable
> - it doesn't work
I hate to say this, but I've been working on something very similar
just in the past days, with the notable difference that I'm using
stream-oriented AF_UNIX sockets instead of datagram-oriented.
I have a similar use case, and after some experiments I picked a
stream-oriented socket over datagram-oriented because:
- overhead appears to be the same
- message boundaries make little sense here -- you already have a
32-bit vnet header with the message size defining the message
boundaries
- datagram-oriented AF_UNIX sockets are actually reliable and there's
no packet reordering on Linux, but this is not "formally" guaranteed
- it's helpful for me to know when a qemu instance disconnects for any
reason
> As a side note, I tried to pass in an already open FD, but that
> didn't work either.
This actually worked for me as a quick work-around, either with:
https://github.com/StevenVanAcker/udstools
or with a trivial C implementation of that, that does essentially:
fd = strtol(argv[1], NULL, 0);
if (fd < 3 || fd > INT_MAX || errno)
usage(argv[0]);
s = socket(AF_UNIX, SOCK_STREAM, 0);
if (s < 0) {
perror("socket");
exit(EXIT_FAILURE);
}
if (connect(s, (const struct sockaddr *)&addr, sizeof(addr)) < 0) {
perror("connect");
exit(EXIT_FAILURE);
}
if (dup2(s, (int)fd) < 0) {
perror("dup");
exit(EXIT_FAILURE);
}
close(s);
execvp(argv[2], argv + 2);
perror("execvp");
where argv[1] is the socket number you pass in the qemu command line
(-net socket,fd=X) and argv[2] is the path to qemu.
> So, I added some code which does work for me... e.g.
>
> - can specify the socket paths like -netdev
> id=bla,type=socket,unix=/tmp/in:/tmp/out
> - it does forward packets between two Qemu instances running
> back-to-back
>
> I'm wondering if this is of interest for the wider community and, if
> so, how to proceed.
>
> Thanks,
> -ralph
>
> Commit
> https://github.com/rschmied/qemu/commit/73f02114e718ec898c7cd8e855d0d5d5d7abe362
I think your patch could be a bit simpler, as you could mostly reuse
net_socket_udp_init() for your initialisation, and perhaps rename it to
net_socket_dgram_init().
Anyway, I wonder, would my approach work for you instead? I'm posting my
patch in a minute.
--
Stefano
next prev parent reply other threads:[~2021-04-23 15:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 6:56 socket.c added support for unix domain socket datagram transport Ralph Schmieder
2021-04-23 9:16 ` Daniel P. Berrangé
2021-04-23 13:38 ` Ralph Schmieder
2021-04-23 15:29 ` Stefano Brivio [this message]
2021-04-23 15:48 ` Ralph Schmieder
2021-04-23 16:39 ` Stefano Brivio
2021-04-26 11:14 ` Ralph Schmieder
2021-04-27 21:51 ` Stefano Brivio
2021-04-23 16:21 ` Daniel P. Berrangé
2021-04-23 16:54 ` Stefano Brivio
2021-04-26 12:05 ` Ralph Schmieder
2021-04-26 12:56 ` Daniel P. Berrangé
2021-04-27 21:52 ` Stefano Brivio
2021-04-28 9:02 ` Daniel P. Berrangé
2021-04-29 12:07 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210423172940.14f48b49@elisabeth \
--to=sbrivio@redhat.com \
--cc=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=ralph.schmieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.