Hi all, On 2022/10/15 0:10, Morten Brørup wrote: >> From: Bruce Richardson [mailto:[email protected]] >> 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 <[email protected]> wrote: >>> >>>> On Fri, Oct 14, 2022 at 12:44:33PM +0000, Power, Ciara wrote: >>>>> Hi Chengwen, >>>>> >>>>>> -----Original Message----- >>>>>> From: David Marchand <[email protected]> >>>>>> Sent: Friday 14 October 2022 10:50 >>>>>> To: Chengwen Feng <[email protected]> >>>>>> Cc: [email protected]; [email protected]; Power, Ciara >>>>>> <[email protected]> >>>>>> Subject: Re: [PATCH v2] usertools: telemetry json support >> pretty print >>>>>> >>>>>> On Fri, Oct 14, 2022 at 5:31 AM Chengwen Feng >> <[email protected]> >>>>>> 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 <[email protected]> >>>>>> >>>>>> 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.
Already fix in v3. > >>>>> >>>>>> >>>>>> 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. The v3 support indent only under interactive mode. >>>> >>>> /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. :-) +1 for not being worthwhile. > > 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? > > > . >
