From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
iommu@lists.linux-foundation.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: i915 and swiotlb_max_segment
Date: Thu, 03 Jun 2021 11:40:10 +0300 [thread overview]
Message-ID: <162270961054.11739.9148402963893484386@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <YKZ8eqnSnaso3aoe@0xbeefdead.lan>
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> >
> > swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> > SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> > size when swiotlb is otherwise enabled.
> >
> > i915 then uses it to:
> >
> > a) decided on the max order in i915_gem_object_get_pages_internal
> > b) decide on a max segment size in i915_sg_segment_size
> >
> > for a) it really seems i915 should switch to dma_alloc_noncoherent
> > or dma_alloc_noncontigous ASAP instead of using alloc_page and
> > streaming DMA mappings. Any chance I could trick one of the i915
> > maintaines into doing just that given that the callchain is not
> > exactly trivial?
> >
> > For b) I'm not sure swiotlb and i915 really agree on the meaning
> > of the value. swiotlb_set_max_segment basically returns the entire
> > size of the swiotlb buffer, while i915 seems to use it to limit
> > the size each scatterlist entry. It seems like dma_max_mapping_size
> > might be the best value to use here.
>
> Yes. The background behind that was SWIOTLB would fail because well, the
> size of the sg was too large. And some way to limit it to max size
> was needed - the dma_max_mapping_size "should" be just fine.
>
> >
> > Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> > a horribly confusing API.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
iommu@lists.linux-foundation.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: i915 and swiotlb_max_segment
Date: Thu, 03 Jun 2021 11:40:10 +0300 [thread overview]
Message-ID: <162270961054.11739.9148402963893484386@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <YKZ8eqnSnaso3aoe@0xbeefdead.lan>
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> >
> > swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> > SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> > size when swiotlb is otherwise enabled.
> >
> > i915 then uses it to:
> >
> > a) decided on the max order in i915_gem_object_get_pages_internal
> > b) decide on a max segment size in i915_sg_segment_size
> >
> > for a) it really seems i915 should switch to dma_alloc_noncoherent
> > or dma_alloc_noncontigous ASAP instead of using alloc_page and
> > streaming DMA mappings. Any chance I could trick one of the i915
> > maintaines into doing just that given that the callchain is not
> > exactly trivial?
> >
> > For b) I'm not sure swiotlb and i915 really agree on the meaning
> > of the value. swiotlb_set_max_segment basically returns the entire
> > size of the swiotlb buffer, while i915 seems to use it to limit
> > the size each scatterlist entry. It seems like dma_max_mapping_size
> > might be the best value to use here.
>
> Yes. The background behind that was SWIOTLB would fail because well, the
> size of the sg was too large. And some way to limit it to max size
> was needed - the dma_max_mapping_size "should" be just fine.
>
> >
> > Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> > a horribly confusing API.
WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
iommu@lists.linux-foundation.org
Subject: Re: [Intel-gfx] i915 and swiotlb_max_segment
Date: Thu, 03 Jun 2021 11:40:10 +0300 [thread overview]
Message-ID: <162270961054.11739.9148402963893484386@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <YKZ8eqnSnaso3aoe@0xbeefdead.lan>
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
> On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
> > Hi all,
> >
> > swiotlb_max_segment is a rather strange "API" export by swiotlb.c,
> > and i915 is the only (remaining) user.
> >
> > swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if
> > SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment
> > size when swiotlb is otherwise enabled.
> >
> > i915 then uses it to:
> >
> > a) decided on the max order in i915_gem_object_get_pages_internal
> > b) decide on a max segment size in i915_sg_segment_size
> >
> > for a) it really seems i915 should switch to dma_alloc_noncoherent
> > or dma_alloc_noncontigous ASAP instead of using alloc_page and
> > streaming DMA mappings. Any chance I could trick one of the i915
> > maintaines into doing just that given that the callchain is not
> > exactly trivial?
> >
> > For b) I'm not sure swiotlb and i915 really agree on the meaning
> > of the value. swiotlb_set_max_segment basically returns the entire
> > size of the swiotlb buffer, while i915 seems to use it to limit
> > the size each scatterlist entry. It seems like dma_max_mapping_size
> > might be the best value to use here.
>
> Yes. The background behind that was SWIOTLB would fail because well, the
> size of the sg was too large. And some way to limit it to max size
> was needed - the dma_max_mapping_size "should" be just fine.
>
> >
> > Once that is fixed I'd like to kill off swiotlb_max_segment as it is
> > a horribly confusing API.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-06-03 8:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 15:25 i915 and swiotlb_max_segment Christoph Hellwig
2021-05-10 15:25 ` [Intel-gfx] " Christoph Hellwig
2021-05-20 15:12 ` Konrad Rzeszutek Wilk
2021-05-20 15:12 ` [Intel-gfx] " Konrad Rzeszutek Wilk
2021-05-20 15:12 ` Konrad Rzeszutek Wilk
2021-06-03 8:40 ` Joonas Lahtinen [this message]
2021-06-03 8:40 ` [Intel-gfx] " Joonas Lahtinen
2021-06-03 8:40 ` Joonas Lahtinen
2021-06-03 9:17 ` [Intel-gfx] " Tvrtko Ursulin
2021-06-03 9:17 ` Tvrtko Ursulin
2021-06-03 9:17 ` Tvrtko Ursulin
2021-06-03 10:54 ` Robin Murphy
2021-06-03 10:54 ` Robin Murphy
2021-06-03 10:54 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=162270961054.11739.9148402963893484386@jlahtine-mobl.ger.corp.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jani.nikula@linux.intel.com \
--cc=konrad.wilk@oracle.com \
--cc=rodrigo.vivi@intel.com \
--cc=tvrtko.ursulin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.