> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Tuesday, March 13, 2018 10:21 AM
> To: Van Haaren, Harry <harry.van.haa...@intel.com>; Lu, Wenzhuo
> <wenzhuo...@intel.com>; Wu, Jingjing <jingjing...@intel.com>
> Cc: email@example.com; Shahaf Shuler <shah...@mellanox.com>; Yongseok Koh
> 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-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> >> Sent: Monday, March 12, 2018 5:53 PM
> >> To: Lu, Wenzhuo <wenzhuo...@intel.com>; Wu, Jingjing
> >> Cc: firstname.lastname@example.org; Yigit, Ferruh <ferruh.yi...@intel.com>; Shahaf Shuler
> >> <shah...@mellanox.com>; Yongseok Koh <ys...@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
> > --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  . 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
> 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
I suggest postponing that as future work, existing patch is fine with me as is.