Off-topic: D-Bus in the kernel

[Alban Crequy]

Le Fri, 17 Sep 2010 16:04:55 +0200,
Mohamed Ikbel Boulabiar <boulabiar at gmail.com> a écrit :

> I have 2 questions:
> 
> Anyone have tried performance improvements other than a simple
> ping-pong ?

Hi,

I tested 3 performance tests and I listed them there:
http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/

I chose the ping-pong because this use-case shows the better
performance improvements.

I also chose the Jabber connection on the N900 with Telepathy because it
is an user-oriented test and it generates a lot of D-Bus traffic between
the connection manager, the address book, the widgets on the desktop.

If you have an idea of sensible test, I can give it a try.

> Are we speaking about putting DBus in kernel by
> rethinking it's design and how it can be divided to kernelSpace +
> userSpace components ?

The protocol and semantic from the applications point of view didn't
change. It is just a new kind of socket supported, in addition to the
existing support for Unix sockets and TCP sockets. I think it is
important that no changes are required in applications. Only a small
patch in libdbus (6 files changed, 333 insertions(+), 1 deletions(-)).

The support for Unix/TCP sockets is not removed and will not be
deprecated: it will still be needed on non-Linux platforms and peer to
peer connections at least. dbus-daemon listens on AF_DBUS socket only
if the configuration file says so with <listen/>.


How to divide between kernel space and user space is a good question
and it is not decided. Here are my thoughts about the division and how
it is currently implemented in the kdbus prototype:

- Match rules and message dispatching: they need to be done in
  kernel space. Otherwise we would still need to context switch to the
  dispatcher (dbus-daemon) so there would be no gain.

- Security policy: I want to explore netlink to let dbus-daemon uploads
  them to kdbus. At the moment, it is not implemented, so it is open
  for all :-)

- Creating the buses: buses are still initiated from user land when
  dbus-daemon listen() on an AF_DBUS socket. Nothing changes here
  compared to other socket types.

- D-Bus activation: I am thinking to let dbus-daemon do that unless you
  have a better proposition. The prototype deliver a message to
  dbus-daemon when the recipient is a well-known name absent from the
  bus. So the kernel module does not need to know the list of
  activatable services. In this case, dbus-daemon wakes up but it is
  not a performance problem.

- Client authentication: I don't know. At the moment, the prototype let
  dbus-daemon handling that by delivering all messages which does not
  look like a D-Bus message (i.e. the NULL byte and the commands like
  "AUTH", "BEGIN", etc.) to dbus-daemon.

- The bus driver (who replies to D-Bus method calls to
  org.freedesktop.DBus): I don't see the value to put this in the
  kernel but I'm happy to be proven wrong. kdbus needs to know which
  connection own which unique name and well-known name. In the
  prototype, kdbus spies the "NameAcquired" and "NameLost" signals for
  that purpose.

-- 
Alban