lkml.org 
[lkml]   [2012]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX
On 03/05/2012 03:05 PM, Martin Mares wrote:
> Hi!
>
>> Please check the link above and tell me if that different than the
>> model you suggested using BPF, apparently we are talking about the
>> very same solution but the implementation detail are getting in the
>> way because a lot of code was added.
>
> ...
>
> First of all, you should come up with some real data confirming that
> the problem you are trying to solve really exist -- i.e., that in some
> real (and sensible) setup, routing all messages through DBUS daemon
> is a bottleneck.
>
> Have a nice fortnight

We still don't have performance numbers for D-bus using AF_UNIX
multicast since our D-bus daemon branch is still not stable. But Alban
did some tests for the first approach (creating a new socket address
family AF_DBUS) and the performance gain was x1.8 for KVM/i386 and x3
for N900/ARM.

Alban's blog entry can be found here:
http://alban-apinc.blogspot.com/2011/12/d-bus-in-kernel-faster.html

Yes, D-bus has many architectural flaws that has to be addressed. The
out-of-order delivery requirement maybe is not even important in real
world and the control flow is something that probably we can fix in
user-space too. That every message has to pass through the D-bus daemon
is something that can also be fixed without requiring any kernel
modification.

But there is one problem that we can't solve without Linux kernel
support. The fact that multicast messages have to be directly sent to
the receivers.

The problem is that Linux lacks of an easy IPC mechanism to send
multicast messages to processes in the same machine. We can use UDP
multicast over IP but even when the sending/receiving performance is
similar to our AF_UNIX multicast implementation, the connection setup is
much more complex.

We will investigate if we can use Netlink sockets as an multicast IPC
mechanism even when it is designed for the kernel-space/user-space use
case and not well suited to user-space/user-space communication.

Best regards,
Javier


\
 
 \ /
  Last update: 2012-03-05 16:13    [W:0.108 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site