Re: kdbus: add documentation

[Florian Weimer <fw-d32yF4oPJVt0XxTmqZlbVQ@public.gmane.org>]

* David Herrmann:

> poll(2) and friends cannot return data for changed descriptors. I
> think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this
> turns out to be a bottleneck, we can provide bulk-operations in the
> future. Anyway, I don't see how a _shared_ pool would change any of
> this?

I responded to Andy's messages because it seemed to be about
generalizing the pool functionality.

>> kernel could also queue the data for one specific recipient,
>> addressing the same issue that SO_REUSEPORT tries to solve (on poll
>> notification, the kernel does not know which recipient will eventually
>> retrieve the data, so it has to notify and wake up all of them).
>
> We already queue data only for the addressed recipients. We *do* know
> all recipients of a message at poll-notification time. We only wake up
> recipients that actually got a message queued.

Exactly, but poll on, say, UDP sockets, does not work this way.  What
I'm trying to say is that this functionality is interesting for much
more than kdbus.

> Not sure how this is related to SO_REUSEPORT. Can you elaborate on
> your optimizations?

Without something like SO_REUSEPORT, it is a bad idea to have multiple
threads polling the same socket.  The semantics are such that the
kernel has to wake *all* the waiting threads, and one of them will
eventually pick up the datagram with a separate system call.  But the
kernel does not know which thread this will be.

With SO_REUSEPORT and a separately created socket for each polling
thread, the kernel will only signal one poll operation because it
assumes that any of the waiting threads will process the datagram, so
it's sufficient just to notify one of them.

kdbus behaves like the latter, but also saves the need to separately
obtain the datagram and related data from the kernel.