On Sat, Sep 16, 2023 at 02:34:06PM +0200, Stefano Brivio wrote:
> Hi Nikolay,
> 
> On Fri, 15 Sep 2023 18:21:52 +0400
> Nikolay Edigaryev <edigaryev@gmail.com> 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.


I second that point.  I think having a different option for passing an
fd is a much better interface design than having a secondary option
which affects the interpretation of another one.

> > 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.
> 

-- 
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