netdev.vger.kernel.org archive mirror
 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
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, Eyal Birger <eyal@nsof.io>
Subject: [PATCH ipsec-next,v2 0/3]  xfrm: support collect metadata mode for xfrm interfaces
Date: Thu, 25 Aug 2022 16:46:33 +0300	[thread overview]
Message-ID: <20220825134636.2101222-1-eyal.birger@gmail.com> (raw)

From: Eyal Birger <eyal@nsof.io>

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     | 220 +++++++++++++++++++++++++++++++---
 net/xfrm/xfrm_policy.c        |  10 +-
 8 files changed, 263 insertions(+), 28 deletions(-)

----

v2: add "link" property as suggested by Nicolas Dichtel

-- 
2.34.1


             reply	other threads:[~2022-08-25 13:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 13:46 Eyal Birger [this message]
2022-08-25 13:46 ` [PATCH ipsec-next,v2 1/3] net: allow storing xfrm interface metadata in metadata_dst Eyal Birger
2022-08-25 13:46 ` [PATCH ipsec-next,v2 2/3] xfrm: interface: support collect metadata mode Eyal Birger
2022-08-25 14:24   ` Nikolay Aleksandrov
2022-08-25 15:14     ` Eyal Birger
2022-08-26  7:53       ` Nicolas Dichtel
2022-08-27 12:36         ` Nikolay Aleksandrov
2022-08-25 14:28   ` Nicolas Dichtel
2022-08-25 13:46 ` [PATCH ipsec-next,v2 3/3] xfrm: lwtunnel: add lwtunnel support for xfrm interfaces in collect_md mode Eyal Birger
2022-08-25 14:30   ` Nikolay Aleksandrov
2022-08-25 14:30   ` Nicolas Dichtel

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=20220825134636.2101222-1-eyal.birger@gmail.com \
    --to=eyal.birger@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=contact@proelbtn.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=eyal@nsof.io \
    --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=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;
as well as URLs for NNTP newsgroup(s).