Re: [EARLY RFC][PATCH 0/4] dmabuf pools infrastructure (destaging ION)

From: Laura Abbott <labbott@redhat.com>
To: John Stultz <john.stultz@linaro.org>, "Andrew F. Davis" <afd@ti.com>
Cc: Chenbo Feng <fengc@google.com>,
	Alistair Strachan <astrachan@google.com>,
	Liam Mark <lmark@codeaurora.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [EARLY RFC][PATCH 0/4] dmabuf pools infrastructure (destaging ION)
Date: Fri, 22 Feb 2019 14:30:44 -0800	[thread overview]
Message-ID: <6f4237bd-3a2e-9b69-fe44-69dfc11fa0db@redhat.com> (raw)
In-Reply-To: <CALAqxLX+BZV-h2k8W060zcRD_LxOz4WyfHnUyqDJGCtXPLSJ4w@mail.gmail.com>

On 2/22/19 9:24 AM, John Stultz wrote:
> On Fri, Feb 22, 2019 at 8:55 AM Andrew F. Davis <afd@ti.com> wrote:
>> On 2/21/19 1:40 AM, John Stultz wrote:
>>> Here is a very early peek at my dmabuf pools patchset, which
>>> tries to destage a fair chunk of ION functionality.
>>>
>>> This build and boots, but I've not gotten to testing the actual
>>> pool devices yet (need to write some kselftests)! I just wanted
>>> some early feedback on the overall direction.
>>>
>>> The patchset implements per-pool devices (extending my ion
>>> per-heap devices patchset from last week), which can be opened
>>> directly and then an ioctl is used to allocate a dmabuf from the
>>> pool.
>>>
>>> The interface is similar, but simpler then IONs, only providing
>>> an ALLOC ioctl.
>>>
>>> Also, I've only destaged the system/system-contig and cma pools,
>>> since the ION carveout and chunk heaps depended on out of tree
>>> board files to initialize those heaps. I'll leave that to folks
>>> who are actually using those heaps.
>>>
>>> Let me know what you think!
>>>
>>
>> +1
>>
>> Was this source not pulled from -next, I have some fixes in next that I
>> don't see in this code, so I won't review the code itself just yet (it
>> is and early RFC after all). For the concept itself I have a couple
>> small suggestions:
> 
> Oh, no, I've missed those. I was working off -rc7. I'll try to
> re-integrate them in.
> 
>> I'm not sure I like the name. "Pool" in the context of DMA-BUF feels
>> like it means something else, like some new feature of DMA-BUFs
>> exporters/importers can use for making buffer pools. How about just keep
>> the "heap" terminology to prevent too much re-wording. Maybe just call
>> this dma-buf/heaps/ ?
> 
> The name changing was mostly as Laura noted that the term heap has
> caused confusion historically. I'm not really particular, and I do
> worry about the naming overlap between dmabuf-pools and the pagepool
> code was problematic. Due to that overlap, renaming things back will
> be a small chore, but I've got only myself to blame there :)
> 
> 

Yeah I'm not set on changing the names. If everyone else finds
heap to be descriptive enough, we can keep it.

Thanks,
Laura
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel