Amount of D-Bus messages with Telepathy

[Alban Crequy]

Le Wed, 26 Jan 2011 16:06:39 +0000,
Simon McVittie <simon.mcvittie at collabora.co.uk> a écrit :

> On Wed, 26 Jan 2011 at 10:55:19 -0500, Havoc Pennington wrote:
> > One thing that may be important for performance is how often these are
> > round trips.
> 
> This email was missing a bit of context; it's a reply to the thread
> I just started about profiling D-Bus, following some IRC discussion, and
> giving some numbers for (one) real-world use of D-Bus. The ratios
> between, for instance, messages to the bus daemon and messages to peers
> affect which bits it makes sense to try to optimize, either in dbus-daemon
> or by replacing them with kdbus.

It looks like the messages to the bus daemon are an important part of
communication that I underestimated. In my Telepathy scenario, it takes 60% of
method calls. In my regular usage of the GNOME desktop, it still took about 33%.

The effects of kdbus on AddMatch/RemoveMatch messages depends on how it is
implemented. I see 2 possible ways to add the match rules with kernel-dbus
support:

1/ the client adds a socket filter with the match rule on the dbus socket and
there is no need to send the 'AddMatch' message to dbus-daemon. dbus-daemon is
not woken up and it does not know clients' match rules.
 => cost: 1 system call setsockopt()

2/ the client sends the 'AddMatch' message to dbus-daemon and dbus-daemon sets up
the socket filter for the client.
 => cost: 3 system calls send(), setsockopt(), send() + 2 context switches

The significant number of 'AddMatch' messages advocates for the first solution.
But I also like the second solution because:

- dbus-daemon controls the socket filters installed on clients, so it can put
  some security limits, such as avoiding eavesdropping.

- when dbus-daemon knows the match rules, it is easier to debug too broad match
  rules with the GetConnectionMatchRules patch (#24307)

- it does not require changes in the clients, only dbus-daemon.


-- 
Alban