On Thu, 23 Feb 2023 14:07:25 +0000
Ferruh Yigit <ferruh.yi...@amd.com> wrote:
> Overall I am not sure if anyone is interested in driver datapath logs
> other than driver developers themselves.
>
> For datapath logging I think there are two concerns,
> 1) It should not eat *any* cycles unless explicitly enabled
> 2) Capability of enable/disable them because of massive amount of log it
> can generate
>
>
> Currently there are two existing approaches for driver datapath logging:
> i) Controlled by 'RTE_ETHDEV_DEBUG_RX/TX' compile time flag,
> when enabled 'rte_log()' is used with Rx/Tx specific log type.
> ii) 'RTE_LOG_DP' ', compile time control per logtype via
> 'RTE_LOG_DP_LEVEL',
> when enabled 'rte_log()' is used with PMD logtype.
>
>
> In (ii), need to re-compile code when you need to increase the log
> verbosity, and it leaks to production code as mentioned above.
>
> For (i), developer compiles once enabling debug, later can fine grain
> log level dynamically. This is more DPDK developer focused approach.
>
>
> [1]
> According above, what do you think to retire 'RTE_LOG_DP', (at least
> within ethdev datapath), and chose (i) as preferred datapath logging?
I agree, the current tx/rx logging is a mess.
Each driver is different, each driver has to have something to enable it;
and it really isn't useful beyond the driver developer.
Using tracing seems like a much better option. Could we agree on a common
set of trace points for drivers and fix all drivers to use the same thing.
Probably will cause some upset among driver developers:
"where did my nice printf's go, now I have to learn tracing"
but DPDK has a good facility here, lets use it.
My proposal would be:
- agree on common set of trace points
- apply to all drivers
- remove RTE_LOG_DP()
- remove per driver RX/TX options
- side effect, more uses of RTE_LOGTYPE_PMD go away.
