[systemd-devel] [RFC 4/8] HACK0: allow meta information customizable

[AKASHI Takahiro]

On 06/25/2014 06:56 PM, Daniel Mack wrote:
> Hi,
>
> On 06/25/2014 11:13 AM, AKASHI Takahiro wrote:
>> My ftrace log shows that kdbus_meta_append(), is one of dominant functions
>> in sending a message, while the other is kdbus_conn_queue_alloc().
>> This patch adds an extra argument to kdbus_hello() utility function and
>> allows us to explicitly specify meta information attached to a message
>> for performance evaluation.
>>
>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>> ---
>>   test/kdbus-util.c |   35 +++++++++++++++++++++--------------
>>   test/kdbus-util.h |    2 ++
>>   2 files changed, 23 insertions(+), 14 deletions(-)
>
> Note that the kernel features of kdbus are defined by the kernel code,
> not by the convenience wrappers for ioctl() that live in test/. As soon
> as you start to implement your own code using kdbus features, I'd
> strongly recommend you start over and implement your own low-level
> functions. The ioctl API is actually simple enough to do this.

This patch in my patchset might have misguided you.
I know that the existing ioctl has a feature of customizing meta information
attached to a message. What this patch does is just to modify a test utility function,
kdbus_hello(), temporarily to see the performance differences with and without
meta info.

I never say that meta info is meaningless, but
I would like people to be more careful about it not only because choosing an appropriate set
of meta info does make sense, but also because it has quit big impact on latency.

The original test/test-kdbus-benchmark also uses kdbus_hello(), and so the performance can
look worse. (In other words, the worst case numbers?)

Assuming that attaching meta is necessary but its also expensive, it might be a good idea
to have and check meta info not per message, but per connection. (In this case, we may have to
invent higher-level protocol/concept).

What do you think of that?

Thanks,
-Takahiro AKASHI


> Same counts for patch #2 and #3 of this series.
>
>
> Thanks,
> Daniel
>