RE: [PATCH v2] usertools: telemetry json support pretty print

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@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.richardson@intel.com> wrote:
> >
> > > On Fri, Oct 14, 2022 at 12:44:33PM +0000, Power, Ciara wrote:
> > > > Hi Chengwen,
> > > >
> > > > > -----Original Message-----
> > > > > From: David Marchand <david.marchand@redhat.com>
> > > > > Sent: Friday 14 October 2022 10:50
> > > > > To: Chengwen Feng <fengchengwen@huawei.com>
> > > > > Cc: thomas@monjalon.net; dev@dpdk.org; Power, Ciara
> > > > > <ciara.power@intel.com>
> > > > > Subject: Re: [PATCH v2] usertools: telemetry json support
> pretty print
> > > > >
> > > > > On Fri, Oct 14, 2022 at 5:31 AM Chengwen Feng
> <fengchengwen@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 <fengchengwen@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?