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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E750EC76186 for ; Wed, 24 Jul 2019 22:32:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B296621850 for ; Wed, 24 Jul 2019 22:32:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=fomichev-me.20150623.gappssmtp.com header.i=@fomichev-me.20150623.gappssmtp.com header.b="qmdbW9TG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728930AbfGXWcN (ORCPT ); Wed, 24 Jul 2019 18:32:13 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:34368 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728826AbfGXWcN (ORCPT ); Wed, 24 Jul 2019 18:32:13 -0400 Received: by mail-pg1-f193.google.com with SMTP id n9so15689495pgc.1 for ; Wed, 24 Jul 2019 15:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fomichev-me.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=661OL/iR1qoYlwUkzlekgkKWwDhi9Py/1hATN7T3Ahc=; b=qmdbW9TGbpD4u+r2iyOlnYVTL9rTlUFPcF5T5BCUPblJVVLGwqa0ii9UlX6PZXMplF v7/LjVjosR4oJWqlCcoVdbSmX6oBThkQ8hDeS69QzbPU71D7qbczM+it2tgA9ZKcc9U9 ioRvfcp2MwlD3oVgJPjHBHZpBH8dwnfHgxOuiAm7RRaYYCI+M+MhXcc+KHfU9I5jaOr9 uJdmRixV5IqK83nYNDnHoxU0efIdPG9MphzBhEMqMILFU+AtTkdbFd27R9PId7li7smf OvFYDnNmr3pAyXhRvRBHo9lbwLRxQWN185/+Ljhq4QNrvePhYWFatx45NAEFqoaZLdOS ySSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=661OL/iR1qoYlwUkzlekgkKWwDhi9Py/1hATN7T3Ahc=; b=eGZ6RVftmYT3OWHz7JG69gRnB5qNixtiVrLFlfZzMq7yaiwMl2whgu6Vd14pMvCvYz w6S0WqWRfChAd+yGitbBHBq0xoj/7E8iJH4ds6jU7938NYZ/hiC4euJcG/BZrecdEyR9 Tcr2CWb4vOE0QxJq86gUOYqvQl7tJVhx3o1eL9OxXpVSO3uCOSW3Cx5gvq6Xv++xmv9E yEi1rjoT2sfhHux5Zy+fJ8tk5DIlrV9oshvSBP8cIlCY1OuWapN7w9aE1NnNT9LXxz71 3QHyZ8Vx4Obbc1ILsmbYNQ2hXLrnWG1j0nbzYs1Uz2Ikh/vNOgabeG122VwAoKuKjwYg VglA== X-Gm-Message-State: APjAAAWW8pxK6gB2sMpAXrgVGtSVXevR/JlVZTtNIqmeRPNvw2naHTpv L2xMnkOqyP1yJKV4GEq6hbM= X-Google-Smtp-Source: APXvYqwYGuSVzdaYps1FpPZOx447i2vB+efYxBYoZ554d2jsFTYzKkVFH52RIDtsgb3p918sVmq9Qg== X-Received: by 2002:a63:61cd:: with SMTP id v196mr2365471pgb.210.1564007532269; Wed, 24 Jul 2019 15:32:12 -0700 (PDT) Received: from localhost ([2601:646:8f00:18d9:d0fa:7a4b:764f:de48]) by smtp.gmail.com with ESMTPSA id q1sm56690279pfg.84.2019.07.24.15.32.11 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 24 Jul 2019 15:32:11 -0700 (PDT) Date: Wed, 24 Jul 2019 15:32:10 -0700 From: Stanislav Fomichev To: Song Liu Cc: Stanislav Fomichev , Networking , bpf , "David S . Miller" , Alexei Starovoitov , Daniel Borkmann , Willem de Bruijn , Petar Penkov Subject: Re: [PATCH bpf-next 1/7] bpf/flow_dissector: pass input flags to BPF flow dissector program Message-ID: <20190724223210.GA3500@mini-arch> References: <20190724170018.96659-1-sdf@google.com> <20190724170018.96659-2-sdf@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 07/24, Song Liu wrote: > On Wed, Jul 24, 2019 at 10:11 AM Stanislav Fomichev wrote: > > > > C flow dissector supports input flags that tell it to customize parsing > > by either stopping early or trying to parse as deep as possible. Pass > > those flags to the BPF flow dissector so it can make the same > > decisions. In the next commits I'll add support for those flags to > > our reference bpf_flow.c > > > > Cc: Willem de Bruijn > > Cc: Petar Penkov > > Signed-off-by: Stanislav Fomichev > > --- > > include/linux/skbuff.h | 2 +- > > include/net/flow_dissector.h | 4 ---- > > include/uapi/linux/bpf.h | 5 +++++ > > net/bpf/test_run.c | 2 +- > > net/core/flow_dissector.c | 5 +++-- > > 5 files changed, 10 insertions(+), 8 deletions(-) > > > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h > > index 718742b1c505..9b7a8038beec 100644 > > --- a/include/linux/skbuff.h > > +++ b/include/linux/skbuff.h > > @@ -1271,7 +1271,7 @@ static inline int skb_flow_dissector_bpf_prog_detach(const union bpf_attr *attr) > > > > struct bpf_flow_dissector; > > bool bpf_flow_dissect(struct bpf_prog *prog, struct bpf_flow_dissector *ctx, > > - __be16 proto, int nhoff, int hlen); > > + __be16 proto, int nhoff, int hlen, unsigned int flags); > > > > bool __skb_flow_dissect(const struct net *net, > > const struct sk_buff *skb, > > diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h > > index 90bd210be060..3e2642587b76 100644 > > --- a/include/net/flow_dissector.h > > +++ b/include/net/flow_dissector.h > > @@ -253,10 +253,6 @@ enum flow_dissector_key_id { > > FLOW_DISSECTOR_KEY_MAX, > > }; > > > > -#define FLOW_DISSECTOR_F_PARSE_1ST_FRAG BIT(0) > > -#define FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL BIT(1) > > -#define FLOW_DISSECTOR_F_STOP_AT_ENCAP BIT(2) > > - > > struct flow_dissector_key { > > enum flow_dissector_key_id key_id; > > size_t offset; /* offset of struct flow_dissector_key_* > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index fa1c753dcdbc..b4ad19bd6aa8 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -3507,6 +3507,10 @@ enum bpf_task_fd_type { > > BPF_FD_TYPE_URETPROBE, /* filename + offset */ > > }; > > > > +#define FLOW_DISSECTOR_F_PARSE_1ST_FRAG (1U << 0) > > +#define FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL (1U << 1) > > +#define FLOW_DISSECTOR_F_STOP_AT_ENCAP (1U << 2) > > Do we have to move these? These have to be a part of UAPI one way or another. The easiest thing we can do is to call the existing flags a UAPI and move them into exported headers. Alternatively, we can introduce new set of UAPI flags and do some kind of conversion between exported and internal ones. Since it's pretty easy to add/deprecate them (see cover letter), I've decided to just move them instead of adding another set and doing conversion. I'm open to suggestions if you think otherwise.