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
