All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Eyal Birger <eyal.birger@gmail.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
	<pabeni@redhat.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>,
	<netdev@vger.kernel.org>, <bpf@vger.kernel.org>
Subject: Re: [PATCH ipsec-next,v4 0/3] xfrm: support collect metadata mode for xfrm interfaces
Date: Tue, 30 Aug 2022 09:47:40 +0200	[thread overview]
Message-ID: <20220830074740.GO2950045@gauss3.secunet.de> (raw)
In-Reply-To: <20220826114700.2272645-1-eyal.birger@gmail.com>

On Fri, Aug 26, 2022 at 02:46:57PM +0300, Eyal Birger wrote:
> 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(-)

Applied, thanks a lot Eyal!

      parent reply	other threads:[~2022-08-30  7:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 11:46 [PATCH ipsec-next,v4 0/3] xfrm: support collect metadata mode for xfrm interfaces Eyal Birger
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 ` Steffen Klassert [this message]

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=20220830074740.GO2950045@gauss3.secunet.de \
    --to=steffen.klassert@secunet.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=eyal.birger@gmail.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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.