From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH iproute2 5/5] bpf: implement btf handling and map annotation Date: Thu, 19 Jul 2018 17:43:11 +0200 Message-ID: References: <20180717233122.29390-1-daniel@iogearbox.net> <20180717233122.29390-6-daniel@iogearbox.net> <20180717172743.6e5e1231@cakuba.lan> <20180718111337.165cfd5f@cakuba.lan> <20180719001143.gjh77spvcnujblkc@kafai-mbp.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: dsahern@gmail.com, alexei.starovoitov@gmail.com, netdev@vger.kernel.org To: Martin KaFai Lau , Jakub Kicinski Return-path: Received: from www62.your-server.de ([213.133.104.62]:49710 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731442AbeGSQ1B (ORCPT ); Thu, 19 Jul 2018 12:27:01 -0400 In-Reply-To: <20180719001143.gjh77spvcnujblkc@kafai-mbp.dhcp.thefacebook.com> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 07/19/2018 02:11 AM, Martin KaFai Lau wrote: > On Wed, Jul 18, 2018 at 11:13:37AM -0700, Jakub Kicinski wrote: >> 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. > +1 on the btf subcommand. That would also work, I think both might be useful to have. Former would all sit under a single command to show map details. With 'bpftool btf' you would also allow for a full BTF dump when a specific BTF obj id is provided? >> Having the single map view show more information seems interesting, but >> I wonder if it could be surprising. Is there precedent for such >> behaviour? > Having everything in one page (map show id 123) could be interesting. > One thing is the pahole-like output may be quite long? > e.g. the member of a struct could itself be another struct. Right, though probably fine when you want to see all information specific to one map. Of course the 'bpftool map' list view would need to hide this information. > Not sure how the pahole-like output may look like in json though. Would the existing map k/v dump have more or less the same 'issue'?