[dpdk-dev] [PATCH v3] app/testpmd: print Rx/Tx offload values

[Van Haaren, Harry]

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, March 13, 2018 10:21 AM
> To: Van Haaren, Harry <harry.van.haaren at intel.com>; Lu, Wenzhuo
> <wenzhuo.lu at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> Cc: dev at dpdk.org; Shahaf Shuler <shahafs at mellanox.com>; Yongseok Koh
> <yskoh at mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v3] app/testpmd: print Rx/Tx offload values
> 
> On 3/13/2018 9:24 AM, Van Haaren, Harry wrote:
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> >> Sent: Monday, March 12, 2018 5:53 PM
> >> To: Lu, Wenzhuo <wenzhuo.lu at intel.com>; Wu, Jingjing
> <jingjing.wu at intel.com>
> >> Cc: dev at dpdk.org; Yigit, Ferruh <ferruh.yigit at intel.com>; Shahaf Shuler
> >> <shahafs at mellanox.com>; Yongseok Koh <yskoh at mellanox.com>
> >> Subject: [dpdk-dev] [PATCH v3] app/testpmd: print Rx/Tx offload values
> >>
> >> Which per port offloads are enabled is not clear. Printing offloads
> >> values at forwarding start.
> >>
> >> CRC strip offload value was printed in more verbose manner, it is
> >> removed since Rx/Tx offload values covers it and printing only CRC one
> >> can cause confusion.
> >>
> >> Hexadecimal offloads values are not very user friendly but preferred to
> >> not create to much noise during forwarding start.
> >
> >
> > Hmmm - I'm thinking is there a better method to reduce verbosity, but keep
> > user friendliness?
> >
> > Can the dynamic logs be used? By default, just print the hex mask, but
> with
> > --log-level="pmd.net.*.offload_flags" we print the list, itemized?
> >
> > crc strip .......... 1
> > vlan strip ......... 1
> > udp checksum ....... 0
> 
> As Yongseok mentioned 'show port cap all' prints the offload capabilities in
> a more user friendly way [1] [2]. This patch adds a summary config log after
> "start" command, I think it is good to keep it brief.

Apologies I didn't follow this thread from the start, Ack to keep it brief here.


> Related to the "pmd.net.*.offload_flags" suggestion, we are currently using
> log
> types to select components, it can be interesting to use feature based log
> types, ethdev may register them and PMDs can use it.

Yes - we'd need to define what log-levels exist per feature, so there is some consistency.
I suggest postponing that as future work, existing patch is fine with me as is.