> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Sunday, July 12, 2020 9:21 PM
> 
> On Sun, 12 Jul 2020 09:35:23 +0200
> Thomas Monjalon <tho...@monjalon.net> wrote:
> 
> > 11/07/2020 20:58, Ivan Dyukov:
> > > 11.07.2020 14:27, Thomas Monjalon пишет:
> > > > 11/07/2020 12:43, Ivan Dyukov:
> > > >> +__rte_experimental
> > > >> +int rte_eth_link_printf(const char *const fmt,
> > > >> +                       const struct rte_eth_link *eth_link);
> > > >>
> > > > Maybe I missed your reply,
> > > > I still don't understand the need for this function.
> > > >
> > > I used it few times in apps in this patchset.  It allows to avoid code
> > > duplication in examples. i.e. declare array, call rte_eth_link_to_str,
> > > call printf.
> > >
> > > It's simple and usefull function.  Why not?
> >
> > Why not is not a good justification :)
> > We must avoid adding too much in the API.
> >
> >
> 
> I agree with Thomas, this whole exercise seems like a lot of effort for
> a log message that probably should be debug only.

Adding a text formatting function to DPDK is questionable, but that was already 
discussed and approved. And I agree that it is generic enough to be useful.

However, providing a wrapper function to printf the output from a text 
formatting function is not useful. The application can do that. Who is to say 
that stdout is the right output channel for the application anyway... it might 
as well be a debug log, SYSLOG or something else. Certainly application 
specific.

> 
> The DPDK should adopt the policy that all core and drivers print
> no log messages by default, and only log at NOTICE or  higher in case
> of error.

+1

I am totally with Stephen here! Any printf will kill performance. If anything, 
use the log or trace libraries. And the log library does not exactly provide 
"data plane performance", so it should be used with extreme caution.

On a side note: It looks like Cisco considers link status change events ERROR 
severity for operational state changes and NOTICE severity for administrative 
state changes. Source: 
https://networklessons.com/cisco/ccie-routing-switching/cisco-ios-syslog-messages


Reply via email to