[dpdk-dev] [PATCH v3 3/7] net/txgbe: update link setup process of backplane NICs

Ferruh Yigit ferruh.yigit at intel.com
Fri Mar 26 09:55:50 CET 2021


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 <jiawenwu at 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?


More information about the dev mailing list