From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id 44EFA5A026D for ; Sat, 16 Sep 2023 14:34:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694867655; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Twsz4y21CnJa9q8/luqhPTw1aIp5ZJkbgtYfuCdgS90=; b=FUr+Qjx4c5kl6QBCTWISXOVW/xeCwJWud+wTMOoTXRCDoXa3Is7V+9QVbrClJegt7rGrIu zBFs21Rz3DXoBeJ+q87jxZbzzXKm8IH4P15ReSG+u6rLfcN5skGf5aKjHJxqfGU1FdRNsy h9PQrrLI1F8YvQ8xosqmOjrkpaEQd5M= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-571-7sicjHnHN7yPzDGRceubCA-1; Sat, 16 Sep 2023 08:34:09 -0400 X-MC-Unique: 7sicjHnHN7yPzDGRceubCA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2BBB01871D93; Sat, 16 Sep 2023 12:34:09 +0000 (UTC) Received: from elisabeth (unknown [10.39.208.3]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0CFDA10F1BE7; Sat, 16 Sep 2023 12:34:07 +0000 (UTC) Date: Sat, 16 Sep 2023 14:34:06 +0200 From: Stefano Brivio To: Nikolay Edigaryev Subject: Re: [PATCH] passt: introduce --fd-is-tap to allow passing TAP file descriptor Message-ID: <20230916143241.2a7b6c77@elisabeth> In-Reply-To: <20230915142152.73499-1-edigaryev@gmail.com> References: <20230915142152.73499-1-edigaryev@gmail.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: TSGOIVZ4ODLN77LL2P4KE7BZSLJXZLP7 X-Message-ID-Hash: TSGOIVZ4ODLN77LL2P4KE7BZSLJXZLP7 X-MailFrom: sbrivio@redhat.com 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, David Gibson 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: Hi Nikolay, On Fri, 15 Sep 2023 18:21:52 +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 it doesn't seem to be > possible to map the whole IP address, yet the users expect an IP > instead of IP:port combination. > > Requirement #1 is why I've choosen passt and it's pretty much > satisfied (thank you for this great piece of software!). And thanks for the patches! I'm glad to hear it's useful for you (and with Cloud Hypervisor :)). Two comments: > Requirement #2 implies some kind of bridge interface on the host > with one TAP interface for the VM and the other for the passt. > > 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. > > 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. > > 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. > > Solution: introduce --fd-is-tap command-line flag to tell passt > which type of FD it's being passed to and force it to use appropriate > system calls and offset calculation. Did you consider adding another parameter altogether, such as --tap-fd? I'm asking because we recently got a request to add another (similar) interface on that "side", that is, a VSOCK file descriptor, for usage with podman-machine. At that point, a further --fd-is-vsock would look a bit awkward. Further, David Gibson is working on a generalised flow table approach which *should* also allow us to have multiple "taps"... and at that point, somebody might want to pass multiple "--tap-fd" or -F options. I didn't really evaluate if there are drawbacks to that, though -- maybe it's a lot more code. > 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. You should add a Signed-off-by tag here (but in general I can fix up tags myself on merge). Other than that, the patch looks good to me in a general sense. -- Stefano