dmaengine Archive on lore.kernel.org
 help / color / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Serge Semin <fancer.lancer@gmail.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Viresh Kumar <vireshk@kernel.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
	linux-mips@vger.kernel.org, devicetree@vger.kernel.org,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 04/11] dmaengine: Introduce max SG list entries capability
Date: Fri, 17 Jul 2020 13:44:03 +0530
Message-ID: <20200717081403.GL82923@vkoul-mobl> (raw)
In-Reply-To: <20200715170843.w4rwl7zjwfcr7rg2@mobilestation>

On 15-07-20, 20:08, Serge Semin wrote:
> On Wed, Jul 15, 2020 at 04:43:15PM +0530, Vinod Koul wrote:
> > On 10-07-20, 19:14, Serge Semin wrote:
> > > On Fri, Jul 10, 2020 at 02:51:33PM +0300, Peter Ujfalusi wrote:
> > 
> > > > Since we should be able to handle longer lists and this is kind of a
> > > > hint for clients that above this number of nents the list will be broken
> > > > up to smaller 'bursts', which when traversing could cause latency.
> > > > 
> > > > sg_chunk_len might be another candidate.
> > > 
> > > Ok. We've got four candidates:
> > > - max_sg_nents_burst
> > > - max_sg_burst
> > > - max_sg_chain
> > > - sg_chunk_len
> > > 
> > > @Vinod, @Andy, what do you think?
> > 
> 
> > So IIUC your hw supports single sg and in that you would like to publish
> > the length of each chunk, is that correct?
> 
> No. My DMA engine does support only a single-entry SG-list, but the new DMA
> {~~slave~~,channel,device,peripheral,...} capability isn't about the length, but
> is about the maximum number of SG-list entries a DMA engine is able to
> automatically/"without software help" walk through and execute. In this thread
> we are debating about that new capability naming.
> 
> The name suggested in this patch: max_sg_nents. Peter noted (I mostly agree with
> him), that it might be ambiguous, since from it (without looking into the
> dma_slave_caps structure comment) a user might think that it's a maximum number of
> SG-entries, which can be submitted for the DMA engine execution, while in fact it's
> about the DMA engine capability of automatic/burst/"without software intervention"
> SG-list entries walking through. (Such information will be helpful to solve a
> problem discussed in this mailing thread, and described in the cover-letter to
> this patchset. We also discussed it with you and Andy in the framework of this
> patchset many times.)
> 
> As an alternative Peter suggested: max_sg_nents_burst. I also think it's better
> than "max_sg_nents" but for me it seems a bit long. max_sg_burst seems better.
> There is no need in having the "nents" in the name, since SG-list implies a list,
> which main parameter (if not to say only parameter) is the number of entries.
> "burst" is pointing out to the automatic/accelerated/"without software intervention"
> SG-list entries walking through.
> 
> On the second thought suggested by me "max_sg_chain" sounds worse than "max_sg_burst",
> because it also might be perceived as a parameter limiting the number of SG-list
> entries is able to be submitted for the DMA engine execution, while in fact it
> describes another matter.
> 
> Regarding "sg_chunk_len". I think it's ambiguous too, since the "chunk
> length" might be referred to both the entries length and to the sub-SG-list
> length.
> 
> So what do you think? What name is better describing the new DMA capability?

How about max_nents_per_sg or max_nents_sg to signify that this implies
max nents for sg not sg entries. IMO Burst/chain are not better than
max_sg_nents.

-- 
~Vinod

  reply index

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 22:45 [PATCH RESEND v7 00/11] dmaengine: dw: Take Baikal-T1 SoC DW DMAC peculiarities into account Serge Semin
2020-07-09 22:45 ` [PATCH v7 01/11] dt-bindings: dma: dw: Convert DW DMAC to DT binding Serge Semin
2020-07-09 22:45 ` [PATCH v7 02/11] dt-bindings: dma: dw: Add max burst transaction length property Serge Semin
2020-07-09 22:45 ` [PATCH v7 03/11] dmaengine: Introduce min burst length capability Serge Semin
2020-07-09 22:45 ` [PATCH v7 04/11] dmaengine: Introduce max SG list entries capability Serge Semin
2020-07-10  8:31   ` Peter Ujfalusi
2020-07-10  9:27     ` Serge Semin
2020-07-10 11:51       ` Peter Ujfalusi
2020-07-10 16:14         ` Serge Semin
2020-07-15 11:13           ` Vinod Koul
2020-07-15 17:08             ` Serge Semin
2020-07-17  8:14               ` Vinod Koul [this message]
2020-07-17 12:36                 ` Serge Semin
2020-07-09 22:45 ` [PATCH v7 05/11] dmaengine: Introduce DMA-device device_caps callback Serge Semin
2020-07-10  8:45   ` Andy Shevchenko
2020-07-10  9:38     ` Serge Semin
2020-07-13  6:51       ` Vinod Koul
2020-07-13 20:13         ` Serge Semin
2020-07-13 20:55       ` Dave Jiang
2020-07-14 16:08         ` Vinod Koul
2020-07-14 16:18           ` Dave Jiang
2020-07-14 16:29             ` Serge Semin
2020-07-14 16:49               ` Dave Jiang
2020-07-09 22:45 ` [PATCH v7 06/11] dmaengine: dw: Take HC_LLP flag into account for noLLP auto-config Serge Semin
2020-07-09 22:45 ` [PATCH v7 07/11] dmaengine: dw: Set DMA device max segment size parameter Serge Semin
2020-07-09 22:45 ` [PATCH v7 08/11] dmaengine: dw: Add dummy device_caps callback Serge Semin
2020-07-10  8:51   ` Andy Shevchenko
2020-07-10  8:52     ` Andy Shevchenko
2020-07-10  9:45     ` Serge Semin
2020-07-15 12:01       ` Vinod Koul
2020-07-09 22:45 ` [PATCH v7 09/11] dmaengine: dw: Initialize min and max burst DMA device capability Serge Semin
2020-07-09 22:45 ` [PATCH v7 10/11] dmaengine: dw: Introduce max burst length hw config Serge Semin
2020-07-09 22:45 ` [PATCH v7 11/11] dmaengine: dw: Initialize max_sg_nents capability Serge Semin

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=20200717081403.GL82923@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=vireshk@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

dmaengine Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dmaengine/0 dmaengine/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dmaengine dmaengine/ https://lore.kernel.org/dmaengine \
		dmaengine@vger.kernel.org
	public-inbox-index dmaengine

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.dmaengine


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git