From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH iproute2 5/5] bpf: implement btf handling and map annotation Date: Wed, 18 Jul 2018 11:13:37 -0700 Message-ID: <20180718111337.165cfd5f@cakuba.lan> References: <20180717233122.29390-1-daniel@iogearbox.net> <20180717233122.29390-6-daniel@iogearbox.net> <20180717172743.6e5e1231@cakuba.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dsahern@gmail.com, alexei.starovoitov@gmail.com, netdev@vger.kernel.org To: Daniel Borkmann Return-path: Received: from mail-pg1-f196.google.com ([209.85.215.196]:38709 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727635AbeGRSwq (ORCPT ); Wed, 18 Jul 2018 14:52:46 -0400 Received: by mail-pg1-f196.google.com with SMTP id k3-v6so2361346pgq.5 for ; Wed, 18 Jul 2018 11:13:42 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 18 Jul 2018 11:33:22 +0200, Daniel Borkmann wrote: > On 07/18/2018 10:42 AM, Daniel Borkmann wrote: > > On 07/18/2018 02:27 AM, Jakub Kicinski wrote: > >> On Wed, 18 Jul 2018 01:31:22 +0200, Daniel Borkmann wrote: > >>> # bpftool map dump id 386 > >>> [{ > >>> "key": 0, > >>> "value": { > >>> "": { > >>> "value": 0, > >>> "ifindex": 0, > >>> "mac": [] > >>> } > >>> } > >>> },{ > >>> "key": 1, > >>> "value": { > >>> "": { > >>> "value": 0, > >>> "ifindex": 0, > >>> "mac": [] > >>> } > >>> } > >>> },{ > >>> [...] > >> > >> Ugh, the empty keys ("") look worrying, we should probably improve > >> handling of anonymous structs in bpftool :S > > > > Yeah agree, I think it would be nice to see a more pahole style dump > > where we have types and member names along with the value as otherwise > > it might be a bit confusing. > > Another feature that would be super useful imho would be in the /single/ > map view e.g. 'bpftool map show id 123' to have a detailed BTF key+value > type dump, so in addition to the basic map info we show pahole like info > of the structs with length/offsets. That sounds good! We could also consider adding a btf object and commands to interrogate BTF types in the kernel in general.. Perhaps then we could add something like bpftool btf describe map id 123. Having the single map view show more information seems interesting, but I wonder if it could be surprising. Is there precedent for such behaviour?