> -----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: dev@dpdk.org; Shahaf Shuler <shah...@mellanox.com>; Yongseok Koh > <ys...@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-boun...@dpdk.org] On Behalf Of Ferruh Yigit > >> Sent: Monday, March 12, 2018 5:53 PM > >> To: Lu, Wenzhuo <wenzhuo...@intel.com>; Wu, Jingjing > <jingjing...@intel.com> > >> Cc: dev@dpdk.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 > 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.