public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
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, dsahern@kernel.org,
	contact@proelbtn.com, pablo@netfilter.org,
	nicolas.dichtel@6wind.com, razor@blackwall.org,
	daniel@iogearbox.net
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	Eyal Birger <eyal.birger@gmail.com>
Subject: [PATCH ipsec-next,v4 0/3] xfrm: support collect metadata mode for xfrm interfaces
Date: Fri, 26 Aug 2022 14:46:57 +0300	[thread overview]
Message-ID: <20220826114700.2272645-1-eyal.birger@gmail.com> (raw)

This series adds support for "collect_md" mode in XFRM interfaces.

This feature is useful for maintaining a large number of IPsec connections
with the benefits of using a network interface while reducing the overhead
of maintaining a large number of devices.

Currently this is possible by having multiple connections share a common
interface by sharing the if_id identifier and using some other criteria
to distinguish between them - such as different subnets or skb marks.
This becomes complex in multi-tenant environments where subnets collide
and the mark space is used for other purposes.

Since the xfrm interface uses the if_id as the differentiator when
looking for policies, setting the if_id in the dst_metadata framework
allows using a single interface for different connections while having
the ability to selectively steer traffic to each one. In addition the
xfrm interface "link" property can also be specified to affect underlying
routing in the context of VRFs.

The series is composed of the following steps:

- Introduce a new METADATA_XFRM metadata type to be used for this purpose.
  Reuse of the existing "METADATA_IP_TUNNEL" type was rejected in [0] as
  XFRM does not necessarily represent an IP tunnel.

- Add support for collect metadata mode in xfrm interfaces

- Allow setting the XFRM metadata from the LWT infrastructure

Future additions could allow setting/getting the XFRM metadata from eBPF
programs, TC, OVS, NF, etc.

[0] https://patchwork.kernel.org/project/netdevbpf/patch/20201121142823.3629805-1-eyal.birger@gmail.com/#23824575

Eyal Birger (3):
  net: allow storing xfrm interface metadata in metadata_dst
  xfrm: interface: support collect metadata mode
  xfrm: lwtunnel: add lwtunnel support for xfrm interfaces in collect_md
    mode

 include/net/dst_metadata.h    |  31 +++++
 include/net/xfrm.h            |  11 +-
 include/uapi/linux/if_link.h  |   1 +
 include/uapi/linux/lwtunnel.h |  10 ++
 net/core/lwtunnel.c           |   1 +
 net/xfrm/xfrm_input.c         |   7 +-
 net/xfrm/xfrm_interface.c     | 206 ++++++++++++++++++++++++++++++----
 net/xfrm/xfrm_policy.c        |  10 +-
 8 files changed, 248 insertions(+), 29 deletions(-)

----

v4: coding change as suggested by Nicolas Dichtel
v3: coding changes as suggested by Nikolay Aleksandrov and
    Nicolas Dichtel
v2: add "link" property as suggested by Nicolas Dichtel

-- 
2.34.1


             reply	other threads:[~2022-08-26 11:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 11:46 Eyal Birger [this message]
2022-08-26 11:46 ` [PATCH ipsec-next,v4 1/3] net: allow storing xfrm interface metadata in metadata_dst Eyal Birger
2022-08-26 11:53   ` Nicolas Dichtel
2022-08-26 11:46 ` [PATCH ipsec-next,v4 2/3] xfrm: interface: support collect metadata mode Eyal Birger
2022-08-26 11:47 ` [PATCH ipsec-next,v4 3/3] xfrm: lwtunnel: add lwtunnel support for xfrm interfaces in collect_md mode Eyal Birger
2022-08-26 11:58   ` Nicolas Dichtel
2022-08-27 11:45   ` Nikolay Aleksandrov
2022-10-11  6:41   ` Ido Schimmel
2022-10-11  8:03     ` Eyal Birger
2022-08-30  7:47 ` [PATCH ipsec-next,v4 0/3] xfrm: support collect metadata mode for xfrm interfaces Steffen Klassert

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=20220826114700.2272645-1-eyal.birger@gmail.com \
    --to=eyal.birger@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=contact@proelbtn.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    --cc=pabeni@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=razor@blackwall.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