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

[AKASHI Takahiro]

On 06/27/2014 01:32 AM, Daniel Mack wrote:
> 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 :)

I see.
My ultimate goal is to see how we could, or not, use kdbus to implement Binder features
on top of Kdbus. In this sense, I am a bit biased :)

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

Thank you.

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

Caching meta info might be a help, I have no specific idea though.

Thanks,
-Takahiro AKASHI

>
> Thanks,
> Daniel
>