From: Eyal Birger <eyal.birger@gmail.com>
To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, steffen.klassert@secunet.com,
herbert@gondor.apana.org.au, pablo@netfilter.org,
contact@proelbtn.com, dsahern@kernel.org
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
devel@linux-ipsec.org, Eyal Birger <eyal.birger@gmail.com>
Subject: [PATCH ipsec-next 1/3] net: allow storing xfrm interface metadata in metadata_dst
Date: Tue, 23 Aug 2022 18:45:55 +0300 [thread overview]
Message-ID: <20220823154557.1400380-2-eyal.birger@gmail.com> (raw)
In-Reply-To: <20220823154557.1400380-1-eyal.birger@gmail.com>
XFRM interfaces provide the association of various XFRM transformations
to a netdevice using an 'if_id' identifier common to both the XFRM data
structures (polcies, states) and the interface. The if_id is configured by
the controlling entity (usually the IKE daemon) and can be used by the
administrator to define logical relations between different connections.
For example, different connections can share the if_id identifier so
that they pass through the same interface, . However, currently it is
not possible for connections using a different if_id to use the same
interface while retaining the logical separation between them, without
using additional criteria such as skb marks or different traffic
selectors.
When having a large number of connections, it is useful to have a the
logical separation offered by the if_id identifier but use a single
network interface. Similar to the way collect_md mode is used in IP
tunnels.
This patch attempts to enable different configuration mechanisms - such
as ebpf programs, LWT encapsulations, and TC - to attach metadata
to skbs which would carry the if_id. This way a single xfrm interface in
collect_md mode can demux traffic based on this configuration on tx and
provide this metadata on rx.
The XFRM metadata is somewhat similar to ip tunnel metadata in that it
has an "id", and shares similar configuration entities (bpf, tc, ...),
however, it does not use other ip tunnel information, and may have
additional xfrm related criteria added to it in the future, and it also
does not necessarily represent a tunnel as XFRM interfaces support other
modes of operation.
Therefore, a new metadata type is introduced, to be used in subsequent
patches in the xfrm interface and configuration entities.
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
---
include/net/dst_metadata.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
index adab27ba1ecb..7e13210b868f 100644
--- a/include/net/dst_metadata.h
+++ b/include/net/dst_metadata.h
@@ -9,6 +9,7 @@
enum metadata_type {
METADATA_IP_TUNNEL,
METADATA_HW_PORT_MUX,
+ METADATA_XFRM,
};
struct hw_port_info {
@@ -16,12 +17,17 @@ struct hw_port_info {
u32 port_id;
};
+struct xfrm_md_info {
+ u32 if_id;
+};
+
struct metadata_dst {
struct dst_entry dst;
enum metadata_type type;
union {
struct ip_tunnel_info tun_info;
struct hw_port_info port_info;
+ struct xfrm_md_info xfrm_info;
} u;
};
@@ -53,6 +59,16 @@ skb_tunnel_info(const struct sk_buff *skb)
return NULL;
}
+static inline struct xfrm_md_info *skb_xfrm_md_info(const struct sk_buff *skb)
+{
+ struct metadata_dst *md_dst = skb_metadata_dst(skb);
+
+ if (md_dst && md_dst->type == METADATA_XFRM)
+ return &md_dst->u.xfrm_info;
+
+ return NULL;
+}
+
static inline bool skb_valid_dst(const struct sk_buff *skb)
{
struct dst_entry *dst = skb_dst(skb);
@@ -82,6 +98,9 @@ static inline int skb_metadata_dst_cmp(const struct sk_buff *skb_a,
return memcmp(&a->u.tun_info, &b->u.tun_info,
sizeof(a->u.tun_info) +
a->u.tun_info.options_len);
+ case METADATA_XFRM:
+ return memcmp(&a->u.xfrm_info, &b->u.xfrm_info,
+ sizeof(a->u.xfrm_info));
default:
return 1;
}
--
2.34.1
next prev parent reply other threads:[~2022-08-23 17:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 15:45 [PATCH ipsec-next 0/3] xfrm: support collect metadata mode for xfrm interfaces Eyal Birger
2022-08-23 15:45 ` Eyal Birger [this message]
2022-08-23 15:45 ` [PATCH ipsec-next 2/3] xfrm: interface: support collect metadata mode Eyal Birger
2022-08-24 17:06 ` Daniel Borkmann
2022-08-24 18:25 ` Eyal Birger
2022-08-24 21:33 ` Daniel Borkmann
2022-08-23 15:45 ` [PATCH ipsec-next 3/3] xfrm: lwtunnel: add lwtunnel support for xfrm interfaces in collect_md mode Eyal Birger
2022-08-24 15:21 ` Nicolas Dichtel
2022-08-24 18:56 ` Eyal Birger
2022-08-25 10:07 ` Nicolas Dichtel
2022-08-25 13:03 ` Eyal Birger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220823154557.1400380-2-eyal.birger@gmail.com \
--to=eyal.birger@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=contact@proelbtn.com \
--cc=davem@davemloft.net \
--cc=devel@linux-ipsec.org \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox