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=-5.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 B50C3C10F03 for ; Sat, 23 Mar 2019 01:20:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8005121902 for ; Sat, 23 Mar 2019 01:20:01 +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="ggC+9DHj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727733AbfCWBUA (ORCPT ); Fri, 22 Mar 2019 21:20:00 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:40692 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727363AbfCWBUA (ORCPT ); Fri, 22 Mar 2019 21:20:00 -0400 Received: by mail-pg1-f193.google.com with SMTP id u9so2623372pgo.7 for ; Fri, 22 Mar 2019 18:19:59 -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=UQWG7Qbg5yvYaTUpz1CWln7tVYmSgD4ctZwy0pv91Qo=; b=ggC+9DHj2DzuCl6CSpR/wn+P1cwh6RCFCmgRcYcE+Wx7n8lv246nvP/oudn7Sne4hX 2JApMZuqS6VeB67Y3sPLc13AsY2wtwOkxUxEjkojSLALx81HprKLsbdA708ebFMWDXVg x5Y4RjBPUPr2hzwXzw4ZHyl7gvT3cH/tAnIi6CpEKwldz9i36tiZ7eVmnK7KUGx+3Xp9 MI0MBucHHgR7TBFjYgPwkJ5EXSrijCprvofXzRt1GiAuzpaFCbUia8jU0HUEfkkfRN1m gCyLQL66QGMPZkXbaWjgwaxcBQsV1S6m+rUVwArERev3AYjQdrD0XUbWqzYLreFNpmb4 FGiQ== 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=UQWG7Qbg5yvYaTUpz1CWln7tVYmSgD4ctZwy0pv91Qo=; b=qEKoUTLS9VNS6Zm/wXRsfXNDt+ccx3s95FT3C8JPhJGE96Cz3COiTOz+5Q/7fSPJVX 3YmlV98O2lFHT+XPiWAPYAPRL5zGcFuTBawgohP4E88Jako4VPXxwvpsXHYkJW1x5F3t hbkHdOpfjTF0gVeDJzb0m3Ykqm9Dy4+XPauGFwWhMSGHP5KFrthLkR1+ZAy8Va+DRFBk LEM9rYbas3R0ktd62sUYTM/q0kVGgneOL+45ELdA5awGfG4dBkFFiGRdIhWhGccjTVFN u8NMNHMFVv1AoUPdfHLxqVjrNcit2bLpNBck5WSmmNHLAq2unE77IoiOgASvrL2ylCym aqYQ== X-Gm-Message-State: APjAAAWx2SYQ9v3eeuVHifDVRMirHvDQgQ0qs+PvrWE4h8D3Ns6s9pcF 4IKDSksHJfCq5K1ZRSvrvXDx4Q== X-Google-Smtp-Source: APXvYqwgskeemA4F+of5V1p+z2mCBlHdeKrd75Io2E2E3+ZCN6weh3drQ5OEKUhuDIwp9Rxpe37u2g== X-Received: by 2002:a17:902:848d:: with SMTP id c13mr73844plo.279.1553303998852; Fri, 22 Mar 2019 18:19:58 -0700 (PDT) Received: from localhost ([2601:646:8f00:18d9:d0fa:7a4b:764f:de48]) by smtp.gmail.com with ESMTPSA id u20sm8017533pga.76.2019.03.22.18.19.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 22 Mar 2019 18:19:58 -0700 (PDT) Date: Fri, 22 Mar 2019 18:19:57 -0700 From: Stanislav Fomichev To: Alexei Starovoitov Cc: Stanislav Fomichev , netdev@vger.kernel.org, bpf@vger.kernel.org, davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net, simon.horman@netronome.com, willemb@google.com, peterpenkov96@gmail.com Subject: Re: [RFC bpf-next v3 6/8] flow_dissector: handle no-skb use case Message-ID: <20190323011957.GY7431@mini-arch.hsd1.ca.comcast.net> References: <20190322195903.162516-1-sdf@google.com> <20190322195903.162516-7-sdf@google.com> <20190323010049.dbywat3n6kfelwth@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190323010049.dbywat3n6kfelwth@ast-mbp.dhcp.thefacebook.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 03/22, Alexei Starovoitov wrote: > On Fri, Mar 22, 2019 at 12:59:01PM -0700, Stanislav Fomichev wrote: > > When called without skb, gather all required data from the > > __skb_flow_dissect's arguments and use recently introduces > > no-skb mode of bpf flow dissector. > > > > Note: WARN_ON_ONCE(!net) will now trigger for eth_get_headlen users. > > > > Signed-off-by: Stanislav Fomichev > > + struct bpf_flow_keys flow_keys; > > + struct bpf_flow_dissector ctx = { > > + .flow_keys = &flow_keys, > > + .data = data, > > + .data_end = data + hlen, > > + .protocol = proto, > > + }; > > + > > + if (skb) { > > + ctx.skb = skb; > > + ctx.protocol = skb->protocol; > > + ctx.vlan_tci = skb->vlan_tci; > > + ctx.vlan_proto = skb->vlan_proto; > > + ctx.vlan_present = skb->vlan_present; > > + } > > are you suggesting to have vlan* fields that only work properly for skb case? > It means that progs/bpf_flow.c would not work as-is for eth_get_headlen. > And to have unified program that works in both cases the program would need to rely > on above internal implementation detail, like checking that ctx->protocol == 0 ? > imo that is worse than having two different flow dissector program types. Yeah. The reference implementation (bpf_flow.c) should handle it though. In parse_eth_proto we handle ETH_P_8021Q/ETH_P_8021AD, so I'm not sure why we even had that skb->vlan_present check in the first place. [But, again, who knows what's out there besides bpf_flow.c] In general, this RFC's approach is to have a "best effort" vlan detection, bpf program would still have to handle it. Agree, that it's confusing. > May be remove protocol and vlan* from ctx ? > Then the only thing program can do is look at the packet data which is > eth_get_headlen use case. For skb case the existence of vlan can be retrofitted into > dissector results by the kernel after the program finished. Are we ok with breaking api in this case? I'm all in on removing this extra information. We can always put it back if somebody complains (and manually parse in eth_get_headlen case). Regarding dissector results: that's currently not implemented, we don't export vlan information. We can still have protocol, because in both skb/skb-less cases we have it.