Received-SPF: pass (google.com: domain of linux-kernel+bounces-29383-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
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: <1cd7b8ef-a450-974e-cb7a-c4928b726d7d@amd.com>
Date: Wed, 17 Jan 2024 11:58:54 -0800
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: [RESEND PATCH V7 0/2] AMD QDMA driver
Content-Language: en-US
To: Mark Harfouche <mark@ramonaoptics.com>
CC: <vkoul@kernel.org>, <dmaengine@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <nishad.saraf@amd.com>,
	<sonal.santan@amd.com>, <max.zhen@amd.com>
References: <1701277940-25645-1-git-send-email-lizhi.hou@amd.com>
 <CAHespK8FOpW6OkEfCSFZaGvJU2z5QmbBAXcZiQCvTfpTk4-Rtg@mail.gmail.com>
From: Lizhi Hou <lizhi.hou@amd.com>
In-Reply-To: <CAHespK8FOpW6OkEfCSFZaGvJU2z5QmbBAXcZiQCvTfpTk4-Rtg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jan 2024 19:58:55.5977
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e5d2629-442e-427d-67b7-08dc1796bc9b
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:
	SN1PEPF000252A2.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8298

Hi Mark,


The QDMA driver has been restructured for upstreaming. And the first 
QDMA patchset supports only AXI4-MM DMA transfers (mentioned in cover 
letter). Directly comparing code with QDMA git repo will not work well.

After QDMA driver patchset is merged, I believe you may submit a fix 
patch to dmaengine for any issue you encounter. We will review your 
patch and verify it with our hardware.


I do not work on the QDMA git repo or forum. I am not the right person 
for questions about QDMA git repo.


Hopefully, this helps.


Thanks,

Lizhi

On 1/14/24 09:54, Mark Harfouche wrote:
> On Wed, Nov 29, 2023 at 12:13 PM Lizhi Hou <lizhi.hou@amd.com> wrote:
>
>
>     Comparing to AMD/Xilinx XDMA subsystem,
>     https://lore.kernel.org/lkml/Y+XeKt5yPr1nGGaq@matsya/
>     the QDMA subsystem is a queue based, configurable scatter-gather DMA
>     implementation which provides thousands of queues, support for
>     multiple
>     physical/virtual functions with single-root I/O virtualization
>     (SR-IOV),
>     and advanced interrupt support. In this mode the IP provides
>     AXI4-MM and
>     AXI4-Stream user interfaces which may be configured on a per-queue
>     basis.
>     [...]
>     This patch series is to provide the platform driver for AMD QDMA
>     subsystem
>     to support AXI4-MM DMA transfers. More functions, such as AXI4-Stream
>     and SR-IOV, will be supported by future patches.
>
>
> Hello,
>
> My name is Mark Harfouche and I've been following the kernel mailing 
> for some time. I'm sorry if this message is coming months after the 
> initial post. Please let me know if there is a more appropriate venue 
> for this kind of message.
>
> Since 2018 we use QDMA, and continue to build the driver ourselves 
> (with some patches).
> I am really excited to see QDMA mature and become part of the linux 
> kernel.
>
> I wanted to share my experience with the QDMA driver and how I (and 
> other users) feel of how they react to feedback.
>
> Early in its development, the QDMA code base was constantly changing, 
> often breaking the userland code that we were writing to interface 
> with it.
> Beyond this, during our testing, we found it was full of unsafe usage 
> of string operations (for example, sprintf being used in the kernel 
> code without checking the validity of inputs).
> The most breaking changes often included the insertion of variables in 
> enum definitions in the netlink interface (which does not seem 
> included in this original set of patches).
>
> The community of users (beyond just me) has tried in many cases to 
> communicate small compatibility issues between kernel versions, and 
> suggested in many cases fixes in the form of small patches. All of 
> which were met with utter silence. Numerous examples on 
> https://github.com/Xilinx/dma_ip_drivers/pulls
> Some examples of breaking changes to enums (the interface between the 
> kernel code and the userland applications using netlink) can be found 
> between 2020 and today by looking at diffs in the qdma_nl.h (again 
> this file seems absent from the patches) 
> https://github.com/Xilinx/dma_ip_drivers/compare/2020.2...master#diff-4497b037af6c3a4f9ac917e639b58a1fa155feb4b62b7fe66741a42ed74cdfd6
>
> While I understand that in 2018-2022 the driver was not considered 
> stable, I am wondering what kind of mechanism for user feedback will 
> be available now that these patches are being submitted to the linux 
> kernel. Will the community be able to submit patches that resolve the 
> issues we find? Is AMD/Xilinx willing to stand behind their API moving 
> forward?
>
> Thank you for your time,
>
> Mark
>
> PS. I may have posted on various Xilinx/AMD/Github forums. My handle 
> there is often mark_ramona or hmaarrfk