Re: kdbus: add documentation

Hi

On Sun, Nov 30, 2014 at 10:08 AM, Florian Weimer [off-list ref] wrote:

* Andy Lutomirski:

quoted

At the risk of opening a can of worms, wouldn't this be much more
useful if you could share a pool between multiple connections?

They would also be useful to reduce context switches when receiving
data from all kinds of descriptors.  At present, when polling, you
receive notification, and then you have to call into the kernel,
again, to actually fetch the data and associated information.

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?

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.

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

Thanks
David