[pulseaudio-discuss] [PATCH 00/11] Introduce memfd support

[Ahmed S. Darwish]

Hi David,

On Fri, Jan 08, 2016 at 02:10:35PM +0100, David Henningsson wrote:
> On 2016-01-02 21:04, Ahmed S. Darwish wrote:
> >Hi!
> 
> 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
> >>memfd.
> >
> >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?

Regards,

-- 
Darwish
http://darwish.chasingpointers.com