[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a851e2eb-9d21-bef8-ef14-d2001ff7a7a6@blackwall.org>
Date: Fri, 26 Aug 2022 13:40:19 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Eyal Birger <eyal.birger@...il.com>, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
steffen.klassert@...unet.com, herbert@...dor.apana.org.au,
dsahern@...nel.org, contact@...elbtn.com, pablo@...filter.org,
nicolas.dichtel@...nd.com, daniel@...earbox.net
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH ipsec-next,v3 1/3] net: allow storing xfrm interface
metadata in metadata_dst
On 25/08/2022 18:46, Eyal Birger wrote:
> 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 necessarily represent an IP tunnel or use other
> ip tunnel information, and also has an optional "link" property which
> can be used for affecting underlying routing decisions.
>
> Additional xfrm related criteria may also be added in the future.
>
> 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@...il.com>
>
> ----
>
> v2: add "link" property as suggested by Nicolas Dichtel
> ---
> include/net/dst_metadata.h | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>
Powered by blists - more mailing lists