> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Friday, 14 October 2022 17.30 > > On Fri, Oct 14, 2022 at 08:01:11AM -0700, Stephen Hemminger wrote: > > On Fri, 14 Oct 2022 14:02:10 +0100 > > Bruce Richardson <bruce.richard...@intel.com> wrote: > > > > > On Fri, Oct 14, 2022 at 12:44:33PM +0000, Power, Ciara wrote: > > > > Hi Chengwen, > > > > > > > > > -----Original Message----- > > > > > From: David Marchand <david.march...@redhat.com> > > > > > Sent: Friday 14 October 2022 10:50 > > > > > To: Chengwen Feng <fengcheng...@huawei.com> > > > > > Cc: tho...@monjalon.net; dev@dpdk.org; Power, Ciara > > > > > <ciara.po...@intel.com> > > > > > Subject: Re: [PATCH v2] usertools: telemetry json support > pretty print > > > > > > > > > > On Fri, Oct 14, 2022 at 5:31 AM Chengwen Feng > <fengcheng...@huawei.com> > > > > > wrote: > > > > > > > > > > > > Currently, the dpdk-telemetry.py show json in raw format, > which is not > > > > > > good for human reading. > > > > > > > > > > > > E.g. The command '/ethdev/xstats,0' will output: > > > > > > {"/ethdev/xstats": {"rx_good_packets": 0, "tx_good_packets": > 0, > > > > > > "rx_good_bytes": 0, "tx_good_bytes": 0, "rx_missed_errors": > 0, > > > > > > "rx_errors": 0, "tx_errors": 0, "rx_mbuf_allocation_errors": > 0, > > > > > > "rx_q0_packets": 0,...}} > > > > > > > > > > > > This patch supports json pretty print by adding extra > indent=4 > > > > > > parameter, so the same command will output: > > > > > > { > > > > > > "/ethdev/xstats": { > > > > > > "rx_good_packets": 0, > > > > > > "tx_good_packets": 0, > > > > > > "rx_good_bytes": 0, > > > > > > "tx_good_bytes": 0, > > > > > > "rx_missed_errors": 0, > > > > > > "rx_errors": 0, > > > > > > "tx_errors": 0, > > > > > > "rx_mbuf_allocation_errors": 0, > > > > > > "rx_q0_packets": 0, > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > Signed-off-by: Chengwen Feng <fengcheng...@huawei.com> > > > > > > > > > > It's indeed easier to read, but maybe 4 chars is too much. > > > > > 2 chars seem enough to me. > > > > [CP] > > > > +1 on using 2 chars
+1 to 2 spaces, following the convention of the rte_<lib>_dump() functions in DPDK. > > > > > > > > > > > > > > In any case I like the idea: > > > > > > I like it too, for interactive use. However, we also have some > hooks in the > > > code for when the app is being run non-interactively i.e. from a > script. In > > > that case, we probably want the indent to be unused. > > > > > > The function "handle_socket()" tracks if the output is a tty via > the "prompt" > > > variable. That could be passed through to the "read_socket()" call > to > > > optionally not-indent the output. > > > > > > /Bruce > > > > Convention in other tools is a -p flag for "pretty output" > > Since we already support detecting interactive use, I think having the > pretty output by default in that case is probably good. +1 to pretty by default. > For non- > interactive > use a -p flag might make sense, but even then I'm not sure it's hugely > worthwhile. +1 to Bruce's comment about not being worthwhile. And we would need the inverse of -p. :-) Closely related: If we agree that the JSON output is either for human or machine consumption, why don't we give JANSSON the JSON_COMPACT flag to save some spaces?
