From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A02AC433EF for ; Wed, 20 Oct 2021 09:58:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4B4D160FE8 for ; Wed, 20 Oct 2021 09:58:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229864AbhJTKAr (ORCPT ); Wed, 20 Oct 2021 06:00:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229809AbhJTKAq (ORCPT ); Wed, 20 Oct 2021 06:00:46 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B99B4C06161C; Wed, 20 Oct 2021 02:58:32 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1md8MR-0001sI-1c; Wed, 20 Oct 2021 11:58:15 +0200 Date: Wed, 20 Oct 2021 11:58:15 +0200 From: Florian Westphal To: Toke =?iso-8859-15?Q?H=F8iland-J=F8rgensen?= Cc: Florian Westphal , Kumar Kartikeya Dwivedi , Maxim Mikityanskiy , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Eric Dumazet , "David S. Miller" , Jakub Kicinski , Hideaki YOSHIFUJI , David Ahern , Jesper Dangaard Brouer , Nathan Chancellor , Nick Desaulniers , Brendan Jackman , Florent Revest , Joe Stringer , Lorenz Bauer , Tariq Toukan , netdev@vger.kernel.org, bpf@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH bpf-next 07/10] bpf: Add helpers to query conntrack info Message-ID: <20211020095815.GJ28644@breakpoint.cc> References: <20211019144655.3483197-1-maximmi@nvidia.com> <20211019144655.3483197-8-maximmi@nvidia.com> <20211020035622.lgrxnrwfeak2e75a@apollo.localdomain> <20211020092844.GI28644@breakpoint.cc> <87h7dcf2n4.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87h7dcf2n4.fsf@toke.dk> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org Toke Høiland-Jørgensen wrote: > Florian Westphal writes: > > > Kumar Kartikeya Dwivedi wrote: > >> On Tue, Oct 19, 2021 at 08:16:52PM IST, Maxim Mikityanskiy wrote: > >> > The new helpers (bpf_ct_lookup_tcp and bpf_ct_lookup_udp) allow to query > >> > connection tracking information of TCP and UDP connections based on > >> > source and destination IP address and port. The helper returns a pointer > >> > to struct nf_conn (if the conntrack entry was found), which needs to be > >> > released with bpf_ct_release. > >> > > >> > Signed-off-by: Maxim Mikityanskiy > >> > Reviewed-by: Tariq Toukan > >> > >> The last discussion on this [0] suggested that stable BPF helpers for conntrack > >> were not desired, hence the recent series [1] to extend kfunc support to modules > >> and base the conntrack work on top of it, which I'm working on now (supporting > >> both CT lookup and insert). > > > > This will sabotage netfilter pipeline and the way things work more and > > more 8-( > > Why? Lookups should be fine. Insertions are the problem. NAT hooks are expected to execute before the insertion into the conntrack table. If you insert before, NAT hooks won't execute, i.e. rules that use dnat/redirect/masquerade have no effect. > > If you want to use netfilter with ebpf, please have a look at the RFC > > I posted and lets work on adding a netfilter specific program type > > that can run ebpf programs directly from any of the existing netfilter > > hook points. > > Accelerating netfilter using BPF is a worthy goal in itself, but I also > think having the ability to lookup into conntrack from XDP is useful for > cases where someone wants to bypass the stack entirely (for accelerating > packet forwarding, say). I don't think these goals are in conflict > either, what makes you say they are? Lookup is fine, I don't see fundamental issues with XDP-based bypass, there are flowtables that also bypass classic forward path via the netfilter ingress hook (first packet needs to go via classic path to pass through all filter + nat rules and is offlloaded to HW or SW via the 'flow add' statement in nftables. I don't think there is anything that stands in the way of replicating this via XDP.