[PATCH v2 0/4] Passt Interface Identifiers
For the generalisations to forwarding we want to accomplish with the flow table, we will need a more formalised notion of passt "interfaces" - that is way that passt communicates with network, whether that be over L4 sockets (as on the host) or via an L2 tunnel. This series makes a small start on this, by introducing a type to identify passt interfaces. We don't use it for a whole lot yet, but it will become more useful in future. Based on the automatic port forwarding cleanup series Changes since v1: * Don't use a type alias for pif ids, just use bare uint8_t David Gibson (4): udp: Clean up ref initialisation in udp_sock_init() pif: Introduce notion of passt/pasta interface pif: Record originating pif in listening socket refs pif: Pass originating pif to tap handler functions Makefile | 2 +- icmp.c | 4 +++- icmp.h | 4 ++-- passt.h | 1 + pif.h | 27 +++++++++++++++++++++++++++ tap.c | 26 ++++++++++++++++---------- tcp.c | 11 ++++++++--- tcp.h | 7 ++++--- tcp_splice.c | 10 ++++++---- udp.c | 35 ++++++++++++++++++----------------- udp.h | 11 ++++++----- 11 files changed, 92 insertions(+), 46 deletions(-) create mode 100644 pif.h -- 2.41.0
udp_sock_init() has a number of paths that initialise uref differently.
However some of the fields are initialised the same way in all of them.
Move those fields into the original initialiser to save a few lines.
Signed-off-by: David Gibson
We have several possible ways of communicating with other entities. We use
sockets to communicate with the host and other network sites, but also in
a different context to communicate "spliced" channels to a namespace. We
also use a tuntap device or a qemu socket to communicate with the namespace
or guest.
For the time being these are just defined implicitly by how we structure
things. However, there are other communication channels we want to use in
future (e.g. virtio-user), and we want to allow more flexible forwarding
between those. To accomplish that we're going to want a specific way of
referring to those channels.
Introduce the concept of a "passt/pasta interface" or "pif" representing a
specific channel to communicate network data. Each pif is assumed to be
associated with a specific network namespace in the broad sense (that is
as a place where IP addresses have a consistent meaning - not the Linux
specific sense). But there could be multiple pifs communicating with the
same namespace (e.g. the spliced and tap interfaces in pasta).
Signed-off-by: David Gibson
For certain socket types, we record in the epoll ref whether they're
sockets in the namespace, or on the host. We now have the notion of "pif"
to indicate what "place" a socket is associated with, so generalise the
simple one-bit 'ns' to a pif id.
Signed-off-by: David Gibson
For now, packets passed to the various *_tap_handler() functions always
come from the single "tap" interface. We want to allow the possibility to
broaden that in future. As preparation for that, have the code in tap.c
pass the pif id of the originating interface to each of those handler
functions.
Signed-off-by: David Gibson
On Tue, 7 Nov 2023 12:40:12 +1100
David Gibson
For the generalisations to forwarding we want to accomplish with the flow table, we will need a more formalised notion of passt "interfaces" - that is way that passt communicates with network, whether that be over L4 sockets (as on the host) or via an L2 tunnel.
This series makes a small start on this, by introducing a type to identify passt interfaces. We don't use it for a whole lot yet, but it will become more useful in future.
Based on the automatic port forwarding cleanup series
Changes since v1: * Don't use a type alias for pif ids, just use bare uint8_t
David Gibson (4): udp: Clean up ref initialisation in udp_sock_init() pif: Introduce notion of passt/pasta interface pif: Record originating pif in listening socket refs pif: Pass originating pif to tap handler functions
Applied. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio