From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [bpf-next RFC 0/3] Introduce eBPF flow dissector Date: Mon, 20 Aug 2018 19:24:46 -0700 (PDT) Message-ID: <20180820.192446.1163576988616844281.davem@davemloft.net> References: <20180816164423.14368-1-peterpenkov96@gmail.com> <20180820205205.jj7e75pulwqkorpr@ast-mbp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: peterpenkov96@gmail.com, netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, simon.horman@netronome.com, ppenkov@google.com, willemb@google.com To: alexei.starovoitov@gmail.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:59410 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725733AbeHUFmx (ORCPT ); Tue, 21 Aug 2018 01:42:53 -0400 In-Reply-To: <20180820205205.jj7e75pulwqkorpr@ast-mbp> Sender: netdev-owner@vger.kernel.org List-ID: From: Alexei Starovoitov Date: Mon, 20 Aug 2018 13:52:07 -0700 > I don't think copy-paste avoids the issue of uapi. > Anything used by BPF program is uapi. > The only exception is offsets of kernel internal structures > passed into bpf_probe_read(). > So we have several options: > 1. be honest and say 'struct flow_dissect_key*' is now uapi > 2. wrap all of them into 'struct bpf_flow_dissect_key*' and do rewrites > when/if 'struct flow_dissect_key*' changes > 3. wait for BTF to solve it for tracing use case and for this one two. ... > The idea is that kernel internal structs can be defined in bpf prog > and since they will be described precisely in BTF that comes with the prog > the kernel can validate that prog's BTF matches what kernel thinks it has. > imo that's the most flexible, but BTF for all of vmlinux won't be ready > tomorrow and looks like this patch set is ready to go, so I would go with 1 or 2. I would definitely prefer #2 or #3. I personally would like to see us avoid preventing interesting optimizations of the flow key layout and/or accesses in the future.