On March 26, 2021 4:56 PM, Ferruh Yigit wrote:
> On 3/26/2021 2:02 AM, Jiawen Wu wrote:
> > On March 25, 2021 6:20 PM, Ferruh Yigit wrote:
> >> On 3/25/2021 5:51 AM, Jiawen Wu wrote:
> >>> Add device arguments to support runtime options.
> >>> And use these configuration to control the link setup flow, to adapt
> >>> to different NIC's construction. Use firmware version to control the
> >>> impact of firmware update. And fix some left bugs.
> >>>
> >>> Signed-off-by: Jiawen Wu <jiawe...@trustnetic.com>
> >>
> >> <...>
> >>
> >>> +#define TXGBE_DEBUG_BP
> >>> +#ifdef TXGBE_DEBUG_BP
> >>> +#define BP_LOG(fmt, ...) \
> >>> + RTE_LOG(CRIT, PMD, "[%lu.%lu]%s(%d): " fmt, \
> >>> + usec_stamp() / 1000000, usec_stamp() % 1000000, \
> >>> + __func__, __LINE__, ## __VA_ARGS__) #else #define
> >> BP_LOG(fmt, ...)
> >>> +do { } while (0) #endif
> >>> +
> >>> #endif /* _TXGBE_LOGS_H_ */
> >>>
> >>
> >> The 'BP_LOG' looks like used for developer debug prints, if so I
> >> suggest removing them completely, but if not can you please convert
> >> it dynamic logging, or using existing dynamic logs 'txgbe_logtype_init',
> 'txgbe_logtype_driver'?
> >>
> >> Thanks,
> >> ferruh
> >
> > I think it should not be removed, since the user needs to adjust 'ffe'
> > parameters according to the logs. I considered converting it to
> > dynamic logging. But when the log level is 'debug', it will result in the
> > printing
> of other logs, which I don't need.
> > Should I lower the log level of 'BP_LOG', to avoid the above situation?
> >
>
> You can create a new logtype for it, and it can be controlled without
> affecting
> other logs, user need to get those logs can enable/disable them in runtime on
> demand, does this work for you?
Got it, thanks!
