rfcs: proposal for a verbose logging mechanism

[avmanerikar]

Link to rendered document.

[mgouicem]

I think a few things are to be clarified here:

• spdlog exposes its own environment variables: how would those interact with ONEDNN_VERBOSE setting?
  For example if a user does not set ONEDNN_VERBOSE, but sets SPDLOG_LEVEL=TRACE, would oneDNN print ? Or if a user sets both, do they combine/override each other?
• if we expose new environment variables, matching APIs will need to be exposed to programatically control that
• in few of the links you provide, spdlog v1 is used, but it seems there are newer releases. Is the recommendation to go with v1 or a specific version?
• Which kind of logger would we use in oneDNN? IIUC, spdlog provides multiple loggers with different properties? In particular, flushing at every message can be necessary for debugging purpose, is there control for that?

[mgouicem]

Could you clarify why is ENABLE_ONEDNN_LOGGING needed?

IIUC, we are switching to spdlog internally for all prints. Based on that, I would expect that only ONEDNN_VERBOSE_FILE is needed, with stdout its default value.

Also, environment variable typically need a matching API.

[avmanerikar]

Good point! The specification of a logfile path should be enough to enable logging in oneDNN. Updating RFC accordingly.

[mgouicem]

in which direction does the mapping go here?

• Is it that oneDNN verbose error messages will be logged with spdlog using SPDLOG_LEVEL_ERROR
• or is it that if a user sets an SPDLOG env variable, we will activate those ONEDNN_VERBOSE flags?

[avmanerikar]

The direction of logging will be from oneDNN to spdlog since no SPDLOG environmental variables are to be used.

[avmanerikar]

I think a few things are to be clarified here:

• spdlog exposes its own environment variables: how would those interact with ONEDNN_VERBOSE setting?
  For example if a user does not set ONEDNN_VERBOSE, but sets SPDLOG_LEVEL=TRACE, would oneDNN print ? Or if a user sets both, do they combine/override each other?
• if we expose new environment variables, matching APIs will need to be exposed to programatically control that
• in few of the links you provide, spdlog v1 is used, but it seems there are newer releases. Is the recommendation to go with v1 or a specific version?
• Which kind of logger would we use in oneDNN? IIUC, spdlog provides multiple loggers with different properties? In particular, flushing at every message can be necessary for debugging purpose, is there control for that?

• The expectation is to not use any of the SPDLOG environmental variables to control logging in oneDNN. With a header-based approach, one can build spdlog without the support for logging using argv /environment var. That way, logging is only controlled programmatically and by using the ONEDNN_VERBOSE settings.
• The latest stable release for spdlog is v1.13 and that is the recommended version to use for logging support. While there is a master branch for spdlog, it is old and deprecated - v1.x is the actual master branch to be used. (See Question: What are the differences in version v.1, master and release gabime/spdlog#1346).
• The proposal is to use a rotating logger for oneDNN as defined here for spdlog. The rotating logger type is useful for keeping the maximum file size in check as the data is logged from several sources.