Okay, so second iteration. The patch is no longer a draft, and numbers
look good; Peter Meerwald has confirmed my numbers of 15 - 25% less CPU in
low latency scenarios (right)?
That said, I guess the patches could use more testing, e g corner cases such
as what happens if either side suddenly dies, if the ringbuffer gets full etc.
Tech overview:
The srchannel (Shared Ringbuffer Channel) is made up of two ringbuffers in
shared memory. For signaling, we use pa_fdsem.
Setting up this srchannel requires the existing mechanism to be improved:
1) We need to pass over the memory block of the ringbuffer. Current PulseAudio has
one SHM area per direction (one for sending memory blocks from server to client,
and one for sending memory blocks from client to server). The buffer is read only
from the other side, and I wanted to keep it that way. However, the ringbuffer
needs to be written from both sides, as it is done with atomic variables.
I therefore added one extra mempool (on the server side), that is used for data
writable from both sides. I also needed to add a special signal/flag to indicate
this in the packet stream.
2) The fdsem used for signaling needs is based on a mechanism called "event file
descriptor", or eventfd. These need to be shared between server and client. The
method for doing this is called "sending ancillary data", and works only over
unix pipes. We already do this with creds today, but I needed to make this work
for eventfds too.
Btw, two of the biggest patches here are mostly search-and-replace stuff:
First, I've replaced pa_creds with pa_ancil through some of the layers, so we can
send/receive both fds and creds.
Second, pstream's do_read function needs to read from the iochannel and the srchannel
in parallel, so we need one "read"-struct for each one.
So all in all, the srchannel itself is a few hundred lines, but the rest shouldn't be
that huge to review.
Also, you should be able to see whether srchannel is enabled or not by looking in the
debug log: when a client connects, the server should say either
Disabling srchannel, reason: ....
or
Enabling srchannel...
Happy reviewing, debugging, testing, and benchmarking!
David Henningsson (11):
creds: Add struct for ancillary data
iochannel/pstream/pdispatch: Add support for receiving file
descriptors
iochannel/pstream: Support sending file descriptors
srchannel: Add the shared ringbuffer object
shm: Allow to open shm in writable mode
memblock, pstream: Allow send/receive of remote writable memblocks
core: Add a second rw mempool
client: Allow client to receive the srchannel memblock
pstream: Allow reading/writing through srchannel
Protocol, client: Add commands to enable ringbuffer
protocol-native: Enable srchannel
PROTOCOL | 15 ++
configure.ac | 2 +-
src/Makefile.am | 3 +-
src/modules/module-tunnel.c | 4 +-
src/pulse/context.c | 88 +++++++++++-
src/pulse/internal.h | 1 +
src/pulsecore/core.c | 14 +-
src/pulsecore/core.h | 5 +-
src/pulsecore/creds.h | 13 ++
src/pulsecore/iochannel.c | 74 ++++++++--
src/pulsecore/iochannel.h | 3 +-
src/pulsecore/memblock.c | 40 +++++-
src/pulsecore/memblock.h | 6 +-
src/pulsecore/native-common.h | 4 +
src/pulsecore/pdispatch.c | 26 +++-
src/pulsecore/pdispatch.h | 4 +-
src/pulsecore/protocol-native.c | 48 ++++++-
src/pulsecore/pstream-util.c | 31 ++++-
src/pulsecore/pstream-util.h | 1 +
src/pulsecore/pstream.c | 299 ++++++++++++++++++++++++++--------------
src/pulsecore/pstream.h | 9 +-
src/pulsecore/shm.c | 12 +-
src/pulsecore/shm.h | 2 +-
src/pulsecore/srchannel.c | 297 +++++++++++++++++++++++++++++++++++++++
src/pulsecore/srchannel.h | 62 +++++++++
25 files changed, 912 insertions(+), 151 deletions(-)
create mode 100644 src/pulsecore/srchannel.c
create mode 100644 src/pulsecore/srchannel.h
--
1.9.1
