Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp1243636rdf; Sat, 4 Nov 2023 12:01:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEUMeot5qQnF4eJatP01HqRsUPA4hmnW9t4k78DBc0XphfNhXFMsZuyE6SWlcksH9W+dCGI X-Received: by 2002:a05:6a21:99a2:b0:153:353e:5e39 with SMTP id ve34-20020a056a2199a200b00153353e5e39mr24546784pzb.51.1699124478860; Sat, 04 Nov 2023 12:01:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1699124478; cv=none; d=google.com; s=arc-20160816; b=u3XheIrsyhVAwQZZd77CdnlxusG8bryooXToY9kCHZamJOLZtyf8iZxH1cZnjXSmWV VNf7Xgt2+htXvi2pL+nQkOAb0Yqmz4bNzYc2kh00R+qlopTpNbfaELZTxv+zDrI+dVvG 9bPuNdXlRG9caGlvPDEDJyvwy4YjczFxWcN6za633zqRQZKquJoUsm9Qr2g1Qil7CDou S0WSeu1nO7S+ZReZU7dgDUKQlSq1lSQzsi//1Ha3NhvxWhbiFrU3vyx3geyDyqeEwfQX pN+N8UnpTzKQUBfd+OktbH1l6LJStQpJgHP7/d/9BcVRHaYrhg1w0EfBaMjzabtL6ctc a/Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:feedback-id:dkim-signature:dkim-signature; bh=jQMa5C9h8+tKW0OeCht46Y9yGFvxlDgodWwXBkYxEyU=; fh=Hcs0cxKAOqs1qB7i8zm7TwL2PftVhDyGhvwvNQctQa4=; b=LCi5AblaVzCo8aCgcPFhjRsrDR3EBLjREA4tz5rUqEdJLRD1TWK7Ki/EcWt4CSOqsK X0lc8GaG0Y1Cug0JuAdCYCUgVVWKPQhmF5RM4DMozgHYXJFPOPY8qoJpj5TbNOoLLpPu fPpTF1ht0g6VewKLz4Nfc0980vVFhGrQ13xPhGaVFLFAcH8wC1lhTrutON8h+UJsCnm1 WHKQV7I9ITTh2CS2oCcPPjbCtlNwK3tMV+EA8EHPhHU4RGWaBRcHquJdB5NYH7K11ZQO eEiIOqIGaRNzYNsqCzO9k/a7EQk9fOtv9gRjjWeJiEuU04hWbhuYVj7teNLkAoEqobB3 Isow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=EbkEtAUc; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PEvrlBBR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id i5-20020a170902cf0500b001cc1af09466si4760053plg.125.2023.11.04.12.01.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Nov 2023 12:01:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@dxuuu.xyz header.s=fm2 header.b=EbkEtAUc; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=PEvrlBBR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 9385A8098491; Sat, 4 Nov 2023 12:01:15 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229810AbjKDSzU (ORCPT + 99 others); Sat, 4 Nov 2023 14:55:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229657AbjKDSzT (ORCPT ); Sat, 4 Nov 2023 14:55:19 -0400 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D68CB184; Sat, 4 Nov 2023 11:55:15 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 054CC320099B; Sat, 4 Nov 2023 14:55:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 04 Nov 2023 14:55:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dxuuu.xyz; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1699124111; x=1699210511; bh=jQMa5C9h8+tKW0OeCht46Y9yGFvxlDgodWw XBkYxEyU=; b=EbkEtAUc0TbMCK1imVKb/RJBQ78mDYJGXAEVcLFrggg8F1XO4HG 2glYOFElsxkOKJ1YpwuLj31xSqoLZPKZd1xOeeF58s6ZdOmJ61Vc6PyVz0mqakFS kcgOf5FeccaBlgsmrDKSdC3aXzyH/NWNaAeQrVoPOD3kuR8W7d5dYXADG3gGTb7r mmn2XWdhvg0cI3gb1kAfJX3aW3WQZnBdrl1x//HPW+KQFYshVW6SfJAP038p1usN x0nXSGVdARVz46AGGdYTZxznFhmPz1AX3gtouzktHpTjaB8L4sGHGuS05TiXnuSk mz705B3wZmZIOmNmJoqU9uQUzjs9FJMeHnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1699124111; x=1699210511; bh=jQMa5C9h8+tKW0OeCht46Y9yGFvxlDgodWw XBkYxEyU=; b=PEvrlBBRk8zMQSk6SvNqatmuT7Fsnl2ZxV6wswm6lo1l+BuSMDi I6cKCVUZaXRplgHtTkEl4sUs29OY7S3TEUmMVPsOsAuHdxLNfAuQPj/r6z4SQtzg gyacOPlAOXKmYC4vfOBdi/NJP9E3FZG1GsLtHJFjC32770wV2J0X3yif66y98cPr tRFhoLJ1CptBVxaLaqO+sMoRXwJ0cVjbiRekWuhB/s1U//u7qtzleeOUAwVSGxbL /NEbFGyDJrNEdNLmpSh93x326vT0s5/2ICHMPBMvweqDqHaWctVDVn+9b+VjUTAy cadOLrJS0S0bwpJYFOJ9i4IXrW8/srFNm+w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddutddguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enfghrlhcuvffnffculddvfedmnecujfgurhepfffhvfevuffkfhggtggugfgjsehtkefs tddttdejnecuhfhrohhmpeffrghnihgvlhcuighuuceougiguhesugiguhhuuhdrgiihii eqnecuggftrfgrthhtvghrnhepueeludeiteejueehudehhfekfeefgeelveduuefgteel veetvddvkeeiveefffdunecuffhomhgrihhnpehsthhrohhnghhsfigrnhdrohhrghdpih gvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepugiguhesugiguhhuuhdrgiihii X-ME-Proxy: Feedback-ID: i6a694271:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 4 Nov 2023 14:55:08 -0400 (EDT) Date: Sat, 4 Nov 2023 12:55:07 -0600 From: Daniel Xu To: Alexei Starovoitov Cc: Jakub Kicinski , Jesper Dangaard Brouer , Eric Dumazet , Steffen Klassert , Daniel Borkmann , Herbert Xu , Alexei Starovoitov , John Fastabend , Paolo Abeni , "David S. Miller" , antony.antony@secunet.com, LKML , Network Development , bpf , devel@linux-ipsec.org Subject: Re: [RFCv2 bpf-next 1/7] bpf: xfrm: Add bpf_xdp_get_xfrm_state() kfunc Message-ID: References: <0a5dc090a098b911bdd19ed0e63c7e466f7054f6.1698875025.git.dxu@dxuuu.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Sat, 04 Nov 2023 12:01:15 -0700 (PDT) On Wed, Nov 01, 2023 at 06:27:03PM -0700, Alexei Starovoitov wrote: > On Wed, Nov 1, 2023 at 2:58 PM Daniel Xu wrote: > > > > This commit adds an unstable kfunc helper to access internal xfrm_state > > associated with an SA. This is intended to be used for the upcoming > > IPsec pcpu work to assign special pcpu SAs to a particular CPU. In other > > words: for custom software RSS. > > > > That being said, the function that this kfunc wraps is fairly generic > > and used for a lot of xfrm tasks. I'm sure people will find uses > > elsewhere over time. > > > > Co-developed-by: Antony Antony > > Signed-off-by: Antony Antony > > Signed-off-by: Daniel Xu > > --- > > include/net/xfrm.h | 9 ++++ > > net/xfrm/Makefile | 1 + > > net/xfrm/xfrm_policy.c | 2 + > > net/xfrm/xfrm_state_bpf.c | 105 ++++++++++++++++++++++++++++++++++++++ > > 4 files changed, 117 insertions(+) > > create mode 100644 net/xfrm/xfrm_state_bpf.c > > > > diff --git a/include/net/xfrm.h b/include/net/xfrm.h > > index c9bb0f892f55..1d107241b901 100644 > > --- a/include/net/xfrm.h > > +++ b/include/net/xfrm.h > > @@ -2190,4 +2190,13 @@ static inline int register_xfrm_interface_bpf(void) > > > > #endif > > > > +#if IS_ENABLED(CONFIG_DEBUG_INFO_BTF) > > +int register_xfrm_state_bpf(void); > > +#else > > +static inline int register_xfrm_state_bpf(void) > > +{ > > + return 0; > > +} > > +#endif > > + > > #endif /* _NET_XFRM_H */ > > diff --git a/net/xfrm/Makefile b/net/xfrm/Makefile > > index cd47f88921f5..547cec77ba03 100644 > > --- a/net/xfrm/Makefile > > +++ b/net/xfrm/Makefile > > @@ -21,3 +21,4 @@ obj-$(CONFIG_XFRM_USER_COMPAT) += xfrm_compat.o > > obj-$(CONFIG_XFRM_IPCOMP) += xfrm_ipcomp.o > > obj-$(CONFIG_XFRM_INTERFACE) += xfrm_interface.o > > obj-$(CONFIG_XFRM_ESPINTCP) += espintcp.o > > +obj-$(CONFIG_DEBUG_INFO_BTF) += xfrm_state_bpf.o > > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c > > index c13dc3ef7910..1b7e75159727 100644 > > --- a/net/xfrm/xfrm_policy.c > > +++ b/net/xfrm/xfrm_policy.c > > @@ -4218,6 +4218,8 @@ void __init xfrm_init(void) > > #ifdef CONFIG_XFRM_ESPINTCP > > espintcp_init(); > > #endif > > + > > + register_xfrm_state_bpf(); > > } > > > > #ifdef CONFIG_AUDITSYSCALL > > diff --git a/net/xfrm/xfrm_state_bpf.c b/net/xfrm/xfrm_state_bpf.c > > new file mode 100644 > > index 000000000000..4aaac134b97a > > --- /dev/null > > +++ b/net/xfrm/xfrm_state_bpf.c > > since net/xfrm/xfrm_interface_bpf.c is already there and > was meant to be use as a file for interface between xfrm and bpf > may be add new kfuncs there instead of new file? IIUC xfrm_interface_bpf.c is for "xfrm interfaces" [0]. See bpf_xfrm_info:if_id. I could be wrong. But if you or Steffen want it all in one file I don't really mind either way. [0]: https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html#_xfrm_interfaces_on_linux > > > > @@ -0,0 +1,105 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* Unstable XFRM state BPF helpers. > > + * > > + * Note that it is allowed to break compatibility for these functions since the > > + * interface they are exposed through to BPF programs is explicitly unstable. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +/* bpf_xfrm_state_opts - Options for XFRM state lookup helpers > > + * > > + * Members: > > + * @error - Out parameter, set for any errors encountered > > + * Values: > > + * -EINVAL - netns_id is less than -1 > > + * -EINVAL - Passed NULL for opts > > + * -EINVAL - opts__sz isn't BPF_XFRM_STATE_OPTS_SZ > > + * -ENONET - No network namespace found for netns_id > > + * @netns_id - Specify the network namespace for lookup > > + * Values: > > + * BPF_F_CURRENT_NETNS (-1) > > + * Use namespace associated with ctx > > + * [0, S32_MAX] > > + * Network Namespace ID > > + * @mark - XFRM mark to match on > > + * @daddr - Destination address to match on > > + * @spi - Security parameter index to match on > > + * @proto - L3 protocol to match on > > + * @family - L3 protocol family to match on > > + */ > > +struct bpf_xfrm_state_opts { > > + s32 error; > > + s32 netns_id; > > + u32 mark; > > + xfrm_address_t daddr; > > + __be32 spi; > > + u8 proto; > > + u16 family; > > +}; > > + > > +enum { > > + BPF_XFRM_STATE_OPTS_SZ = sizeof(struct bpf_xfrm_state_opts), > > +}; > > + > > +__diag_push(); > > +__diag_ignore_all("-Wmissing-prototypes", > > + "Global functions as their definitions will be in xfrm_state BTF"); > > + > > +/* bpf_xdp_get_xfrm_state - Get XFRM state > > + * > > + * Parameters: > > + * @ctx - Pointer to ctx (xdp_md) in XDP program > > + * Cannot be NULL > > + * @opts - Options for lookup (documented above) > > + * Cannot be NULL > > + * @opts__sz - Length of the bpf_xfrm_state_opts structure > > + * Must be BPF_XFRM_STATE_OPTS_SZ > > + */ > > +__bpf_kfunc struct xfrm_state * > > +bpf_xdp_get_xfrm_state(struct xdp_md *ctx, struct bpf_xfrm_state_opts *opts, u32 opts__sz) > > +{ > > + struct xdp_buff *xdp = (struct xdp_buff *)ctx; > > + struct net *net = dev_net(xdp->rxq->dev); > > + > > + if (!opts || opts__sz != BPF_XFRM_STATE_OPTS_SZ) { > > + opts->error = -EINVAL; > > + return NULL; > > + } > > + > > + if (unlikely(opts->netns_id < BPF_F_CURRENT_NETNS)) { > > + opts->error = -EINVAL; > > + return NULL; > > + } > > + > > + if (opts->netns_id >= 0) { > > + net = get_net_ns_by_id(net, opts->netns_id); > > netns is leaking :( Argh, will fix. > > > + if (unlikely(!net)) { > > + opts->error = -ENONET; > > + return NULL; > > + } > > + } > > + > > + return xfrm_state_lookup(net, opts->mark, &opts->daddr, opts->spi, > > + opts->proto, opts->family); > > After looking into xfrm internals realized that > refcnt inc/dec and KF_ACQUIRE maybe unnecessary overhead. > XDP progs run under rcu_read_lock. > I think you can make a version of __xfrm_state_lookup() > without xfrm_state_hold_rcu() and avoid two atomics per packet, > but such xfrm_state may have refcnt==0. > Since bpf prog will only read from there and won't pass it anywhere > else it might be ok. > > But considering the rest of ipsec overhead this might be > a premature optimization and it's better to stay with clean > acquire/release semantics. Yeah I think acquire/release will be fine for now. I've been doing a lot of profiling on tput tests and xdp barely shows up. There are some lower hanging fruit atm. > As far as IETF: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-multi-sa-performance-02 > it's not clear to me why one Child SA (without new pcpu field) > has to be handled by one cpu. > > Sounds like it's possible to implement differently. At least in SW. > In HW, I can see how duplicating multiple crypto state and the rest > in a single queue is difficult. The child SA without pcpu flag (aka fallback SA) is not pinned to a cpu. It's shared between all of the cpus. I think Steffen can probably explain this better if that's not clear. Thanks, Daniel