[pulseaudio-discuss] [PATCH 00/11] Introduce memfd support
Ahmed S. Darwish
darwish.07 at gmail.com
Sat Jan 9 06:09:57 PST 2016
On Fri, Jan 08, 2016 at 02:10:35PM +0100, David Henningsson wrote:
> On 2016-01-02 21:04, Ahmed S. Darwish wrote:
> Hi! Long time no see :-)
Thanks a lot for asking :) Hobby time got a large hit in the past
two months; order is now being restored :-D
> >>The per-client memfd should be set up by the server at SHM negotiation time
> >>(and sealed, but you've said that's a future patch set). Then send a packet
> >>with the memfd as ancil data (or extend PA_COMMAND_ENABLE_SRBCHANNEL, if
> >>that's simpler). This packet should also have an ID that identifies the
> >I'm having a problem in this part. By doing as said above, aren't we
> >limiting the pstream connection to send memblocks only from a _single_
> >memfd-backed pool?
> >Imagine the following:
> >// PA node 1
> >pa_pstream_send_memblock(p, memblock1); // memblock1 is inside pool1
> >pa_pstream_send_memblock(p, memblock2); // memblock2 is inside pool2
> >If pool1 and pool2 are backed by different memfd regions, how would the
> >above suggestion handle that case?
> Hmm, to ask a counter question; why would you put them in different pools in
> the first place? Why would you need more than one pool per pstream?
I don't have a concrete use-case to answer this, but my understanding
is that the two pa_pstream_send_memblock lines above will work as
expected if 'pool1' and 'pool2' were backed by _different_ SHM files.
So when adding memfds as an alternative memory backend, it would be
wise to _keep_ what is working still working .. unless there's a
powerful reason not to.
[discussion continued below ..]
> >If my claim above is valid though, I might just implement in a slightly
> >different way:
> >``Instead of sending the memfd file descriptor at SHM negotiation
> > time, do it in pstream.c::prepare_next_write_item().
> > To avoid the problem of sending the memfd fd for every packet sent,
> > track the memfd-backed blocks earlier sent using their pool's
> > memory backend randomly generated IDs.
> > If this is the first time we encounter this ID, send the memfd file
> > descriptor as ancil data with the packet. If this is not the first
> > encouter, just send the ID without any ancil data. The other end
> > is already tracking this ID and have a mapped memory region opened
> > for it from earlier communication''
> > what do you think?
The above implementation proposal makes sense?
More information about the pulseaudio-discuss