DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: "Montorsi, Francesco" <fmontorsi@empirix.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Proposal: enable redirection of DPDK logs from the user app
Date: Wed, 5 Oct 2016 16:03:49 +0200	[thread overview]
Message-ID: <2a0d7232-fe5b-60a1-616d-84fc9448f050@6wind.com> (raw)
In-Reply-To: <348c536dca594a3fbd38137e2a5a29aa@bilemail1.empirix.com>

Hi Francesco,

On 10/05/2016 03:26 PM, Montorsi, Francesco wrote:
> Hi Olivier,
> 
>> On 10/04/2016 02:28 PM, Montorsi, Francesco wrote:
>>> Yes, but to be honest, that seems a troublesome solution for something
>>> as easy as logging a string; e.g. by using fopencookie() approach, you
>>> don't have the concept of "log message", you just provide a function
>>> that must write a block of bytes somewhere.
>>> Typically instead, you need to know where a log message starts and
>>> ends, to e.g., add prefixes/postfixes to it.
>>
>> I'm not sure that true if you call setbuf(log_stream, NULL).
>>
>> In that case, it looks easy to prefix / postfix messages with a fopencookie
>> callback like:
>>
>> /* example on stdout */
>> ssize_t
>> simple_write(void *c, const char *buf, size_t size) {
>> 	ssize_t ret1, ret2, ret3;
>>
>> 	ret1 = fwrite("<", 1, 1, stdout);
>> 	if (ret1 == 0)
>> 		return 0;
>> 	ret2 = fwrite(buf, size, 1, stdout);
>> 	if (ret2 == 0)
>> 		return 0;
>> 	ret3 = fwrite(">", 1, 1, stdout);
>> 	if (ret3 == 0)
>> 		return 0;
>> 	return ret1 + ret2 + ret3;
>> }
>>
> I didn't know about setbuf()... but are we sure that in this way the simple_write() function will always receive a full string? I mean: in the manpage for setbuf() it says:
> 
> "... When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained. .... If the argument buf is NULL, only the mode is affected; a new buffer will be allocated on the next read or write operation."
> 
> But: is it true that 1 write operation corresponds to 1 vfprintf() call? Maybe if you have a "long" a single vfprintf() call may translate to several simple_write() calls... I don't know honestly.

I did a quick test with a fixed version of simple_write():

ssize_t
simple_write(void *c, const char *buf, size_t size)
{
	ssize_t ret1 = -42, ret3 = -42;
	ssize_t ret = 0;

	ret1 = fwrite("<", 1, 1, stdout);
	if (ret1 == 0)
		goto ret;
	ret = fwrite(buf, 1, size, stdout);
	if (ret != size)
		goto ret;
	ret3 = fwrite(">", 1, 1, stdout);
	if (ret3 == 0)
		goto ret;

ret:
	/* printf("ret=%d ret1=%d ret3=%d\n", (int)ret, (int)ret1, (int)ret3); */
	return ret;
}


It looks like transmitting a string bigger than BUFSIZ (8192) induces
several calls to simple_write(). For smaller calls, it seems there is no
split (1 printf = 1 simple_write).

Of course, this is a just test and not a proof :)
I think we would have a similar issue with the other approach.

For me, the current API looks ok, however let's see the opinion of the
maintainer that could be different of mine. In any case, thank you for
proposing enhancements.

Regards,
Olivier

  reply	other threads:[~2016-10-05 14:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 10:24 Montorsi, Francesco
2016-10-04 11:26 ` Olivier Matz
2016-10-04 12:28   ` Montorsi, Francesco
2016-10-05 12:18     ` Olivier Matz
2016-10-05 13:26       ` Montorsi, Francesco
2016-10-05 14:03         ` Olivier Matz [this message]
2016-10-05 21:22         ` Matthew Hall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a0d7232-fe5b-60a1-616d-84fc9448f050@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=fmontorsi@empirix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).