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

[Daniel Mack]

Hi,

On 06/26/2014 12:33 PM, AKASHI Takahiro wrote:
> On 06/25/2014 06:56 PM, Daniel Mack wrote:
>> On 06/25/2014 11:13 AM, AKASHI Takahiro wrote:

>> 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.

Yes, I've seen that :) And yes, you're right that it does make a
difference. In our benchmark utilities, we so far always considered
more-or-less real use case payloads, but you're right that both timing
values are valuable.

> 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.

Yes of course, I totally understand. Especially when comparing kdbus to
Binder on scale of microseconds, it's just fair to have similar
requirements. And as Binder doesn't support something like meta-data
attachments to messages, you should of course not generate them at all.

My entire point was that I'd recommend you don't use the internal test
framework at all for your benchmark, which is a special use case after
all. That way, the attachment of meta-data wouldn't even have been part
of your performance results :)

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

That's true. I now consider taking the patch and amending the benchmark
tool so that meta data can be switch on or off.

> 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).

That's impossible because the information can change during a
connection's lifetime, and we make the promise of sending accurate,
up-to-date information along with each message, if the user requested it.


Thanks,
Daniel