Re: [PATCH v7 04/11] dmaengine: Introduce max SG list entries capability

On Wed, Jul 15, 2020 at 04:43:15PM +0530, Vinod Koul wrote:

On 10-07-20, 19:14, Serge Semin wrote:

quoted

On Fri, Jul 10, 2020 at 02:51:33PM +0300, Peter Ujfalusi wrote:

quoted

quoted

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?

-Sergey

If so sg_chunk_len seems apt..

-- 
~Vinod