Received-SPF: pass (google.com: domain of linux-kernel+bounces-150579-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
 165.204.84.17 as permitted sender) receiver=protection.outlook.com;
 client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Message-ID: <5e2e2539-38e0-1d3c-62c2-da986da1c68f@amd.com>
Date: Thu, 18 Apr 2024 10:35:44 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH V10 1/1] dmaengine: amd: qdma: Add AMD QDMA driver
Content-Language: en-US
To: Vinod Koul <vkoul@kernel.org>
CC: <dmaengine@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Nishad Saraf
	<nishads@amd.com>, <nishad.saraf@amd.com>, <sonal.santan@amd.com>,
	<max.zhen@amd.com>
References: <1709675352-19564-1-git-send-email-lizhi.hou@amd.com>
 <1709675352-19564-2-git-send-email-lizhi.hou@amd.com>
 <ZhKd7CHXHB7FadY0@matsya> <aa6a63c0-7cce-1f49-4ae5-3e5d93f98fe5@amd.com>
 <ZiAA3C4wXaAHcJ1E@matsya> <14402251-5731-1e52-e787-734d3eb3c801@amd.com>
 <ZiFTheOik-2jsfXP@matsya>
From: Lizhi Hou <lizhi.hou@amd.com>
In-Reply-To: <ZiFTheOik-2jsfXP@matsya>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2024 17:35:45.7808
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1630190d-ddfb-4caa-e8b7-08dc5fcdfab7
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
	CO1PEPF000042AE.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB8557


On 4/18/24 10:08, Vinod Koul wrote:
> On 17-04-24, 10:53, Lizhi Hou wrote:
>> On 4/17/24 10:03, Vinod Koul wrote:
>>> On 08-04-24, 11:06, Lizhi Hou wrote:
>>>
>>>>>> +static void *qdma_get_metadata_ptr(struct dma_async_tx_descriptor *tx,
>>>>>> +				   size_t *payload_len, size_t *max_len)
>>>>>> +{
>>>>>> +	struct qdma_mm_vdesc *vdesc;
>>>>>> +
>>>>>> +	vdesc = container_of(tx, typeof(*vdesc), vdesc.tx);
>>>>>> +	if (payload_len)
>>>>>> +		*payload_len = sizeof(vdesc->dev_addr);
>>>>>> +	if (max_len)
>>>>>> +		*max_len = sizeof(vdesc->dev_addr);
>>>>>> +
>>>>>> +	return &vdesc->dev_addr;
>>>>> Can you describe what metadata is being used here for?
>>>> The metadata is the device address the dma request will transfer
>>>>
>>>> data to / from.  Please see the example usage here:
>>>>
>>>> https://github.com/houlz0507/XRT-1/blob/qdma_v1_usage/src/runtime_src/core/pcie/driver/linux/xocl/subdev/qdma.c#L311
>>>>
>>>> Before dmaengine_submit(), it specifies the device address.
>>> Hmmm, why is the vaddr passed like this, why not use slave_config for
>>> this
>>>
>> This is because the hardware is capable to process multiple vdesc at one
>> kick off.
>>
>> For example, there are two pending vdesc: vd1 and vd2. If there is enough
>> free
>>
>> space in hardware queue, the vd1 and vd2 can be put in queue, and do one
>> kick off
>>
>> to transfer both vd1 and vd2.
>>
>> The destination device address of vd1 and vd2 could be any valid device
>> address.
>>
>> desc_metadata_ptr seems helpful for the per vdesc destination device
>> address.
>>
>>
>> If using slave_config, it needs to call dmaengine_slave_config() and
> That would be the right thing to do...
>
> - set parameters and call dmaengine_slave_config()
> - prep transfer for vd1 dmaengine_prep_slave_sg()
> - set parameters and call dmaengine_slave_config()
> - prep transfer for vd2 dmaengine_prep_slave_sg()
> - submit vd1
> - submit vd2
> - issue_pending
>          - you see you can issue both as you have space, so do that
>
> This should be done always to maximize the dmaengine thoroughput

Thanks for your comments. I will change this.


Lizhi

>
>> dmaengine_prep_slave_sg() with a lock protection. Is this what you would
>> recommend?
>>
>>
>> Thanks,
>>
>> Lizhi