max_outgoing_bytes: What if a D-Bus peer is too slow to read?

[Havoc Pennington]

Hi,

Stepping back for a minute, I bet for this kernel thing to work it
needs to be radically simplified in some way. All the discussions so
far seem to be going in a direction where there'd be hugely divergent
code (and even semantics). It's just too complex to get right. We
should also remember that there is not in fact (afaik) a performance
problem to solve, on desktop hardware; afaik nobody has even profiled
or tuned gdbus which may help a bit ... ?

To be more constructive, maybe the way to go is to come up with one or
two of the most common simple cases, and see if direct delivery is
possible in those cases. Another way to go might be optimizations that
are only allowed with a no-security-policy bus (session bus only, or a
wide-open system bus relying on policykit if people want to audit all
clients).

One userspace-only sort of solution might be to try to automatically
or at least easily create direct sockets between certain clients. So
somehow (application hint?) DBusConnection might decide it should go
direct to client :1.345. It uses the fd passing to get a direct
socket. Messages to that client then go direct. An immediate problem
is retaining ordering of messages. Various possible answers, such as
"only do this when ordering can be sacrificed" or "put some kind of
additional serial in the messages so the peer can reassemble the order
from two sockets."

With some kernel support could imagine a somewhat similar solution for
signals; maybe a client can tell the daemon "there is a direct
multicast socket for this signal name" and any clients who want to
match rule on that signal name would get that socket and could connect
to it directly.

These solutions involve some sort of "direct connection negotiation"
setup step I suppose so are only worth it if you're expecting to send
a lot over the connection. Also, some of the whole idea of dbus was to
avoid an explosion in file descriptors; we actually did have "running
out of fds" as a problem with CORBA, though I guess the max can be
tuned in the kernel, it's still overhead.

There are also the other optimizations besides trying to avoid context
switch, like splice()'ing through large message bodies instead of
copying them to userspace, or whatever. If you knew a message body was
large in advance, the DBusMessage on sender side could go ahead and
allocate it in an aligned page then SPLICE_F_GIFT the message contents
and then the daemon could pass it along and in theory there is only
one copy (in the receiver process). At that point sending large data
blocks through dbus is actually pretty sane.

Trying to reproduce/replicate dbus-daemon semantics... especially with
no detailed spec or test suite... this seems like a dead-end road to
me. It's very complex to put in the kernel, because it's very complex
period...

Havoc