Ferruh, Who can take a look at this?

there is a --syslog parameter which allows you to change the file descriptor to where you would like the output to go would this solve this issue.

map[] = {
		{ "auth", LOG_AUTH },
		{ "cron", LOG_CRON },
		{ "daemon", LOG_DAEMON },
		{ "ftp", LOG_FTP },
		{ "kern", LOG_KERN },
		{ "lpr", LOG_LPR },
		{ "mail", LOG_MAIL },
		{ "news", LOG_NEWS },
		{ "syslog", LOG_SYSLOG },
		{ "user", LOG_USER },
		{ "uucp", LOG_UUCP },
		{ "local0", LOG_LOCAL0 },
		{ "local1", LOG_LOCAL1 },
		{ "local2", LOG_LOCAL2 },
		{ "local3", LOG_LOCAL3 },
		{ "local4", LOG_LOCAL4 },
		{ "local5", LOG_LOCAL5 },
		{ "local6", LOG_LOCAL6 },
		{ "local7", LOG_LOCAL7 },
		{ NULL, 0 }
	};

These are the values you can pass to the parameter --syslog auth etc.

No, that doesn't help at all: there's no way to just go to stderr.
Moreover, stderr should really be the default. No sane library has ever got away with logging to stdout in unix, where stdout pipelines are ubiquitous.

It is possible to change the library logging stream (output) via the following API:
rte_openlog_stream();

To change the output to the 'stderr', it should be:
rte_openlog_stream(stderr);

And if this API called before 'rte_eal_init()' should cause all library log to the 'stderr', which should solve the problem.



After the above said, the library send the log to 'stderr' by default is something to investigate,
normally not all library logs are errors, most of them debug, so the 'stderr' is not an exact fit, but also I can see from the application perspective, the app would like to be in control of what is logged, so the library should not log on its own.

I don't know what is the correct behavior, but I can send a patch to convert the default to 'stderr' and discuss this over the patch.

https://patches.dpdk.org/patch/87830/

Resolved in http://git.dpdk.org/dpdk/commit/?id=5988725d0e