[Intel-gfx] [PATCH v2] drm/i915: Allow compaction upto SWIOTLB max segment size

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 10:51:57PM +0100, Chris Wilson wrote:
> On Wed, Oct 12, 2016 at 05:19:14PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote:
> > > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation
> > > work with SWIOTLB backend") took a heavy handed approach to undo the
> > > scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug
> > > whereby we tried to pass a segment larger than SWIOTLB could handle.) We
> > > can be a little more intelligent and try compacting the scatterlist up
> > > to the maximum SWIOTLB segment size (when using SWIOTLB).
> > > 
> > 
> > Won't this cause a bigger usage of the SWIOTLB bounce buffer ?
> 
> It won't change the frequency of the usage of the bounce buffer, if that
> is what you mean. Either you have intel-iommu and so will not go through
> swiotlb, or you are forced to use swiotlb even though the hw doesn't
> require it (swiotlb config is byzantium and always enabled unless you
> hack it out and can rejoice at the lower cpu usage).

Hahah. Wish that was possible.

Anyhow my concern was with it under Xen, since the page_to_pfn(page) != last_pfn
check is useless there (the PFNs may be contingous but underneath
the machine frame numbers may be discontingous).

And was thinking that this check should be moved to some form of 'DMA-API'
type check, but that screams to me lots of work.

Perhaps expose another swiotlb call to query the preferred size of the
segments. So that you can get the 128 under baremetal SWIOTLB but under Xen
it may expose 1.

But that should not hold up this patch, and can be a followup patch I can
write.

Anyhow for *this* patch:

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>

[as [xen,]swiotlb maintainer, in case you need this].
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre