All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cho KyongHo <pullip.cho@samsung.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: janghyuck.kim@samsung.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, hyesoo.yu@samsung.com,
	iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com
Subject: Re: [PATCH 1/2] dma-mapping: introduce relaxed version of dma sync
Date: Wed, 19 Aug 2020 11:01:26 +0900	[thread overview]
Message-ID: <20200819020121.GA70898@KEI> (raw)
In-Reply-To: <20200818161006.GA25124@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

On Tue, Aug 18, 2020 at 05:10:06PM +0100, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 11:07:57AM +0100, Will Deacon wrote:
> > > > so I'm not sure
> > > > that we should be complicating the implementation like this to try to
> > > > make it "fast".
> > > > 
> > > I agree that this patch makes the implementation of dma API a bit more
> > > but I don't think this does not impact its complication seriously.
> > 
> > It's death by a thousand cuts; this patch further fragments the architecture
> > backends and leads to arm64-specific behaviour which consequently won't get
> > well tested by anybody else. Now, it might be worth it, but there's not
> > enough information here to make that call.
> 
> So it turns out I misread the series (*cough*, crazy long lines,
> *cough*), and it does not actually expose a new API as I thought, but
> it still makes a total mess of the internal interface.  It turns out
> that on the for cpu side we already have arch_sync_dma_for_cpu_all,
> which should do all that is needed.  We could do the equivalent for
> the to device side, but only IFF there really is a major benefit for
> something that actually is mainstream and matters.
> 
Indeed, arch_sync_dma_for_cpu_all() is used where the new internal API
arch_sync_barrier_for_cpu() should be called. I just thought it is a
special hook for MIPS.
In the next version of the patch series, I should consider using
arch_sync_dma_for_cpu_all() and introducting its 'for_dev' version with
some performance data to show the benefit of the change.

Thank you for the proposal.

KyongHo

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Cho KyongHo <pullip.cho@samsung.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: janghyuck.kim@samsung.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, hyesoo.yu@samsung.com,
	iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, robin.murphy@arm.com
Subject: Re: [PATCH 1/2] dma-mapping: introduce relaxed version of dma sync
Date: Wed, 19 Aug 2020 11:01:26 +0900	[thread overview]
Message-ID: <20200819020121.GA70898@KEI> (raw)
In-Reply-To: <20200818161006.GA25124@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

On Tue, Aug 18, 2020 at 05:10:06PM +0100, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 11:07:57AM +0100, Will Deacon wrote:
> > > > so I'm not sure
> > > > that we should be complicating the implementation like this to try to
> > > > make it "fast".
> > > > 
> > > I agree that this patch makes the implementation of dma API a bit more
> > > but I don't think this does not impact its complication seriously.
> > 
> > It's death by a thousand cuts; this patch further fragments the architecture
> > backends and leads to arm64-specific behaviour which consequently won't get
> > well tested by anybody else. Now, it might be worth it, but there's not
> > enough information here to make that call.
> 
> So it turns out I misread the series (*cough*, crazy long lines,
> *cough*), and it does not actually expose a new API as I thought, but
> it still makes a total mess of the internal interface.  It turns out
> that on the for cpu side we already have arch_sync_dma_for_cpu_all,
> which should do all that is needed.  We could do the equivalent for
> the to device side, but only IFF there really is a major benefit for
> something that actually is mainstream and matters.
> 
Indeed, arch_sync_dma_for_cpu_all() is used where the new internal API
arch_sync_barrier_for_cpu() should be called. I just thought it is a
special hook for MIPS.
In the next version of the patch series, I should consider using
arch_sync_dma_for_cpu_all() and introducting its 'for_dev' version with
some performance data to show the benefit of the change.

Thank you for the proposal.

KyongHo

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Cho KyongHo <pullip.cho@samsung.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Will Deacon <will@kernel.org>,
	janghyuck.kim@samsung.com, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org, hyesoo.yu@samsung.com,
	iommu@lists.linux-foundation.org, robin.murphy@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] dma-mapping: introduce relaxed version of dma sync
Date: Wed, 19 Aug 2020 11:01:26 +0900	[thread overview]
Message-ID: <20200819020121.GA70898@KEI> (raw)
In-Reply-To: <20200818161006.GA25124@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]

On Tue, Aug 18, 2020 at 05:10:06PM +0100, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 11:07:57AM +0100, Will Deacon wrote:
> > > > so I'm not sure
> > > > that we should be complicating the implementation like this to try to
> > > > make it "fast".
> > > > 
> > > I agree that this patch makes the implementation of dma API a bit more
> > > but I don't think this does not impact its complication seriously.
> > 
> > It's death by a thousand cuts; this patch further fragments the architecture
> > backends and leads to arm64-specific behaviour which consequently won't get
> > well tested by anybody else. Now, it might be worth it, but there's not
> > enough information here to make that call.
> 
> So it turns out I misread the series (*cough*, crazy long lines,
> *cough*), and it does not actually expose a new API as I thought, but
> it still makes a total mess of the internal interface.  It turns out
> that on the for cpu side we already have arch_sync_dma_for_cpu_all,
> which should do all that is needed.  We could do the equivalent for
> the to device side, but only IFF there really is a major benefit for
> something that actually is mainstream and matters.
> 
Indeed, arch_sync_dma_for_cpu_all() is used where the new internal API
arch_sync_barrier_for_cpu() should be called. I just thought it is a
special hook for MIPS.
In the next version of the patch series, I should consider using
arch_sync_dma_for_cpu_all() and introducting its 'for_dev' version with
some performance data to show the benefit of the change.

Thank you for the proposal.

KyongHo

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2020-08-19  2:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200818075050epcas2p15c780650f5f6b4a54ce731c273d24c98@epcas2p1.samsung.com>
2020-08-18  7:43 ` [PATCH 1/2] dma-mapping: introduce relaxed version of dma sync Cho KyongHo
2020-08-18  7:43   ` Cho KyongHo
2020-08-18  7:43   ` Cho KyongHo
2020-08-18  7:43   ` [PATCH 2/2] arm64: dma-mapping: add relaxed DMA sync Cho KyongHo
2020-08-18  7:43     ` Cho KyongHo
2020-08-18  7:43     ` Cho KyongHo
2020-08-18  8:28   ` [PATCH 1/2] dma-mapping: introduce relaxed version of dma sync Will Deacon
2020-08-18  8:28     ` Will Deacon
2020-08-18  8:28     ` Will Deacon
2020-08-18  8:37     ` Christoph Hellwig
2020-08-18  8:37       ` Christoph Hellwig
2020-08-18  8:37       ` Christoph Hellwig
2020-08-18  9:46       ` Cho KyongHo
2020-08-18  9:46         ` Cho KyongHo
2020-08-18  9:46         ` Cho KyongHo
2020-08-18  9:37     ` Cho KyongHo
2020-08-18  9:37       ` Cho KyongHo
2020-08-18  9:37       ` Cho KyongHo
2020-08-18 10:07       ` Will Deacon
2020-08-18 10:07         ` Will Deacon
2020-08-18 10:07         ` Will Deacon
2020-08-18 16:10         ` Christoph Hellwig
2020-08-18 16:10           ` Christoph Hellwig
2020-08-18 16:10           ` Christoph Hellwig
2020-08-19  2:01           ` Cho KyongHo [this message]
2020-08-19  2:01             ` Cho KyongHo
2020-08-19  2:01             ` Cho KyongHo
2020-08-19  1:24         ` Cho KyongHo
2020-08-19  1:24           ` Cho KyongHo
2020-08-19  1:24           ` Cho KyongHo

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=20200819020121.GA70898@KEI \
    --to=pullip.cho@samsung.com \
    --cc=catalin.marinas@arm.com \
    --cc=hch@infradead.org \
    --cc=hyesoo.yu@samsung.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=janghyuck.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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.