From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 1566E5A026D for ; Tue, 19 Sep 2023 02:46:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1695084412; bh=xrTFfUX2AlM77CZfikgs5Mh4uPl/GBKUlGqno6DlljI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I1Wn9cRKeSrYEAWzAsW5wKxlJLL+nE7E+UPzTUgkh5DNEKLtQQg0JfwNhhx8a5AFw yDG4VAqt7uTSLHCPFo/aWs1x6UoG9vK6Z7FiS7zWXhOz3Z5CteAwTTd/FVssfQXFAm v69GhkIYMdQitW9oXUIAqFXNNeVGEfu7B7OizR4A= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4RqNK829D1z4xNq; Tue, 19 Sep 2023 10:46:52 +1000 (AEST) Date: Tue, 19 Sep 2023 10:45:46 +1000 From: David Gibson To: Nikolay Edigaryev Subject: Re: [PATCH] passt: introduce --tap-fd to allow passing TAP file descriptor Message-ID: References: <20230916143241.2a7b6c77@elisabeth> <20230918133721.5130-1-edigaryev@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="epI8diooqh8/EC+i" Content-Disposition: inline In-Reply-To: <20230918133721.5130-1-edigaryev@gmail.com> Message-ID-Hash: QKBLV5BWBTYY65LPC57KWH2TJSPX2XLC X-Message-ID-Hash: QKBLV5BWBTYY65LPC57KWH2TJSPX2XLC X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --epI8diooqh8/EC+i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 18, 2023 at 05:37:21PM +0400, Nikolay Edigaryev wrote: > Problem: I have a Cloud Hypervisor virtual machine that needs both > (1) an internet access without fiddling with iptables/Netfilter and > (2) VM <-> host access (to be able to provision this VM over SSH > without dealing with passt port forwarding, as it doesn't seem to be > possible to map the whole IP address, yet the users expect an IP > instead of IP:port combination). >=20 > Requirement #1 is why I've choosen passt and it's pretty much > satisfied (thank you for this great piece of software!). >=20 > Requirement #2 implies some kind of bridge interface on the host > with one TAP interface for the VM and the other for the passt. Huh.. ok. I hadn't quite registered that part of this is you're using a tap device, rather than qemu socket, for *passt* rather than pasta, which is not something we've tried before. I'm slightly surprised that you didn't more problems than these. Fwiw, I do think the fact that tap-vs-socket is currently tied to pasta-vs-passt is not really correct and have plans to remove that assumption more cleanly. That's a middling way down the track though, so I'm not necessarily opposed to a stopgap approach. If possible I'd like to keep the user-visible options in such a way that they don't make implementing that future approach harder, of course. > However, only pasta can accept TAP interface FD's in it's -F/--fd, > which is OK, but it also configures unneeded namespacing, which in > turn results in unneeded complexity and performance overhead due > to the need of involving veth pairs to break away from the pasta > namespace to the host for the requirement #2 to be satisfied. Huh, ok, I hadn't considered that angle. A couple of preliminary thoughts: * Since #2 (AFAICT) requires root on the host to set up the bridge, etc., why is using passt still advantageous over just doing all the networking over a bridge? * What do you need from #2 that isn't covered by passt's map-gw limited NAT behaviour? > I've also considered proxying the UNIX domain socket communication > to/from a TAP interface in my own Golang code, but it incurs > significant performance overhead. Yeah, that sounds messy and counter-productive. > On the other hand passt seems to already can do everything I need, > it just needs some guidance on which type of FD it's dealing with. >=20 > Solution: introduce --tap-fd command-line flag to tell passt that we're > passing a TAP FD instead of a UNIX domain socket FD, which will in turn > use appropriate system calls and offset calculaton for that FD. >=20 > This patch also clarifies the -F/--fd description for pasta to note > that we're expecting a TAP device and not a UNIX domain socket. >=20 > Signed-off-by: Nikolay Edigaryev > --- > README.md | 5 +++++ > conf.c | 37 ++++++++++++++++++++++++++++++++++--- > passt.c | 2 ++ > passt.h | 1 + > tap.c | 8 +++++--- > tap.h | 4 ++-- > 6 files changed, 49 insertions(+), 8 deletions(-) >=20 > diff --git a/README.md b/README.md > index 6d00313..760720c 100644 > --- a/README.md > +++ b/README.md > @@ -381,6 +381,11 @@ descriptor that's already opened. > This approach, compared to using a _tap_ device, doesn't require any sec= urity > capabilities, as we don't need to create any interface. > =20 > +However, if you already have a _tap_ device opened by other means, you c= an > +pass it in the `--tap-fd` command-line option and _passt_ will use corre= ct > +system calls and won't send or expect additional QEMU-specific headers f= or > +each packet as it does with the UNIX domain socket. > + I can follow what this is saying in the context of this commit, but I'm not sure it will really make sense solely in the context of where it sits in the README. Not immediately sure how to improve it, alas. > _pasta_ runs out of the box with any recent (post-3.8) Linux kernel. > =20 > ## Services > diff --git a/conf.c b/conf.c > index 0ad6e23..b182904 100644 > --- a/conf.c > +++ b/conf.c > @@ -803,7 +803,12 @@ static void print_usage(const char *name, int status) > UNIX_SOCK_PATH, 1); > } > =20 > - info( " -F, --fd FD Use FD as pre-opened connected socket"); > + if (strstr(name, "pasta")) { > + info( " -F, --fd FD Use FD as pre-opened TAP device"); > + } else { > + info( " -F, --fd FD Use FD as pre-opened and connected UNIX domain= socket"); > + info( " --tap-fd Use FD as pre-opened TAP device"); > + } Huh... so, I didn't fully think through this suggestion in the context of this being for passt rather than pasta. This kind of highlights a bit of ugliness: -F for pasta and -F for passt have different meanings, but -F for pasta has the same meaning as --tap-fd for passt. Sort of, anyway. Reconsidering this, I think a better approach would be to use just a single -F/--fd option, but extend the format of the 'FD' string itself. So, say: -F tap:17 vs -F qsock:17 If the fd type isn't specified, we can default to one or the other differently for pasta and passt, to maintain compatibility. Because the fd is just digits, the various cases shouldn't have any ambiguity. I think that notion of a "type-tagged" fd could also be made use of in the future extensions I have in mind. Stefano, does that seem reasonable to you? > info( " -p, --pcap FILE Log tap-facing traffic to pcap file"); > info( " -P, --pid FILE Write own PID to the given file"); > info( " -m, --mtu MTU Assign MTU via DHCP/NDP"); > @@ -1232,6 +1237,7 @@ void conf(struct ctx *c, int argc, char **argv) > {"config-net", no_argument, NULL, 17 }, > {"no-copy-routes", no_argument, NULL, 18 }, > {"no-copy-addrs", no_argument, NULL, 19 }, > + {"tap-fd", required_argument, NULL, 20 }, > { 0 }, > }; > struct get_bound_ports_ns_arg ns_ports_arg =3D { .c =3D c }; > @@ -1410,6 +1416,27 @@ void conf(struct ctx *c, int argc, char **argv) > =20 > warn("--no-copy-addrs will be dropped soon"); > c->no_copy_addrs =3D copy_addrs_opt =3D true; > + break; > + case 20: > + if (c->mode !=3D MODE_PASST) > + die("--tap-fd is for passt mode only"); > + > + if (c->fd_tap >=3D 0) { > + if (c->mode =3D=3D MODE_PASTA) > + die("Multiple --fd options given"); > + else > + die("Multiple --fd/--tap-fd options given"); > + } > + > + errno =3D 0; > + c->fd_tap =3D strtol(optarg, NULL, 0); > + > + if (c->fd_tap < 0 || errno) > + die("Invalid --tap-fd: %s", optarg); > + > + c->one_off =3D true; > + c->fd_tap_is_socket =3D false; This effectively global boolean flag is ugly, but because it's not directly user visible, I'm ok with that for the time being. I'm happy to subsume it in more general changes once I get to them. > + > break; > case 'd': > if (c->debug) > @@ -1464,8 +1491,12 @@ void conf(struct ctx *c, int argc, char **argv) > =20 > break; > case 'F': > - if (c->fd_tap >=3D 0) > - die("Multiple --fd options given"); > + if (c->fd_tap >=3D 0) { > + if (c->mode =3D=3D MODE_PASTA) > + die("Multiple --fd options given"); > + else > + die("Multiple --fd/--tap-fd options given"); > + } > =20 > errno =3D 0; > c->fd_tap =3D strtol(optarg, NULL, 0); > diff --git a/passt.c b/passt.c > index 8ddd9b3..b7276ff 100644 > --- a/passt.c > +++ b/passt.c > @@ -195,9 +195,11 @@ int main(int argc, char **argv) > } > =20 > c.mode =3D MODE_PASTA; > + c.fd_tap_is_socket =3D false; > log_name =3D "pasta"; > } else if (strstr(name, "passt")) { > c.mode =3D MODE_PASST; > + c.fd_tap_is_socket =3D true; > log_name =3D "passt"; > } else { > exit(EXIT_FAILURE); > diff --git a/passt.h b/passt.h > index 282bd1a..2079cd0 100644 > --- a/passt.h > +++ b/passt.h > @@ -264,6 +264,7 @@ struct ctx { > int epollfd; > int fd_tap_listen; > int fd_tap; > + bool fd_tap_is_socket; > unsigned char mac[ETH_ALEN]; > unsigned char mac_guest[ETH_ALEN]; > =20 > diff --git a/tap.c b/tap.c > index 93db989..12b66ca 100644 > --- a/tap.c > +++ b/tap.c > @@ -76,7 +76,7 @@ int tap_send(const struct ctx *c, const void *data, siz= e_t len) > { > pcap(data, len); > =20 > - if (c->mode =3D=3D MODE_PASST) { > + if (c->fd_tap_is_socket) { > int flags =3D MSG_NOSIGNAL | MSG_DONTWAIT; > uint32_t vnet_len =3D htonl(len); > =20 > @@ -421,7 +421,7 @@ void tap_send_frames(struct ctx *c, const struct iove= c *iov, size_t n) > if (!n) > return; > =20 > - if (c->mode =3D=3D MODE_PASST) > + if (c->fd_tap_is_socket) > m =3D tap_send_frames_passt(c, iov, n); > else > m =3D tap_send_frames_pasta(c, iov, n); > @@ -1176,6 +1176,7 @@ void tap_listen_handler(struct ctx *c, uint32_t eve= nts) > } > =20 > c->fd_tap =3D accept4(c->fd_tap_listen, NULL, NULL, 0); > + c->fd_tap_is_socket =3D true; > =20 > if (!getsockopt(c->fd_tap, SOL_SOCKET, SO_PEERCRED, &ucred, &len)) > info("accepted connection from PID %i", ucred.pid); > @@ -1225,6 +1226,7 @@ static int tap_ns_tun(void *arg) > die("Tap device opened but no network interface found"); > =20 > c->fd_tap =3D fd; > + c->fd_tap_is_socket =3D false; > =20 > return 0; > } > @@ -1273,7 +1275,7 @@ void tap_sock_init(struct ctx *c) > =20 > ASSERT(c->one_off); > ref.fd =3D c->fd_tap; > - if (c->mode =3D=3D MODE_PASST) > + if (c->fd_tap_is_socket) > ref.type =3D EPOLL_TYPE_TAP_PASST; > else > ref.type =3D EPOLL_TYPE_TAP_PASTA; > diff --git a/tap.h b/tap.h > index 021fb7c..3626e49 100644 > --- a/tap.h > +++ b/tap.h > @@ -20,7 +20,7 @@ struct tap_hdr { > =20 > static inline size_t tap_hdr_len_(const struct ctx *c) > { > - if (c->mode =3D=3D MODE_PASST) > + if (c->fd_tap_is_socket) > return sizeof(struct tap_hdr); > else > return sizeof(struct ethhdr); > @@ -52,7 +52,7 @@ static inline void *tap_iov_base(const struct ctx *c, s= truct tap_hdr *taph) > static inline size_t tap_iov_len(const struct ctx *c, struct tap_hdr *ta= ph, > size_t plen) > { > - if (c->mode =3D=3D MODE_PASST) > + if (c->fd_tap_is_socket) > taph->vnet_len =3D htonl(plen + sizeof(taph->eh)); > return plen + tap_hdr_len_(c); > } --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --epI8diooqh8/EC+i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmUI7x4ACgkQzQJF27ox 2GcekA/6AmlsQc0hFbSGg2hg1zApkHm+fQMQ5YzoJE6I+TdaikTJykO2Z0i28Sb8 fnVp9Rh9KhQq6zONZDPME7ccFi5RMS6UZhC32H8b+gDcBwV+pNhqxwbzxe9OMzxj 3f1veRIIVucCnfy0t1oTtrbh5xRrTJNGSaM1jfAc+JInH0cF/eeuPu+T3rzuelhO DV6VZCf/FsGQwLa/jnTj0Dpu+y1iVHcHmp5G9nkxra2XF/JuwiQvnLRYbTUaELTj fA6Dx6iplq6rXvecveq5ZYrhSvvJkeJAGpWE5F6kx6Hb3W/D0HpzwSNxLcjxdeiH iVPY6Vt43ft1cYfQHN8kYGmrJ1+PxsIpY7B/b93yVLxjrcGsemC7QabrVklaq0r6 U+/PSeCbZ1Qq99SnxoifXIssxzTGxan0gErFzwOlFx9ZbBD1GepJqdG/Rjcji6AP 8fZWOIWac6+Ny/NTPIL1Gr7yXVgDiUvBy12qPgial04Ae1txRB90aixzeLc2YN4m uLpSTFfZts0yNZ8AOqjeHss/aMBsVcUxKGwEqyhFhUdQkGXmvHOA6gT6zPUdZat6 wibZ0mbzArzUqFCCSvTAsaKSBjdoVNAgtb8RhgTp+dMaK04JKv0qRNDvSs0XycQ0 tjVhmwMWcxtUhqc7SX6GI+uRgZahexpcRLJJNTYG56hE71+fb04= =HxQS -----END PGP SIGNATURE----- --epI8diooqh8/EC+i--