Re: [PATCH] passt: introduce --fd-is-tap to allow passing TAP file descriptor

[Nikolay Edigaryev <edigaryev@gmail.com>]

Stefano, David, thanks for the input!

I've submitted a new patch completely replacing the previous one
(because I forgot to add --signoff), but only changes the command-line
arguments part as suggested.

The rest is kept the same because I'm not sure if introducing more
than one FD in the passt's context will make sense at this time.

On Sat, Sep 16, 2023 at 4:34 PM Stefano Brivio <sbrivio@redhat.com> 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.
>
> > 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
>