<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> Hi Feng,<o:p></o:p> <o:p> </o:p> Thanks for depicting the feature use case.<o:p></o:p> <o:p> </o:p> From the application’s perspective, inter VM/process communication is required to exchange the src & dst buffer details, however the specifics of this communication mechanism are outside the scope in this context. Regarding the address translations, these buffer addresses can be either IOVA as PA or IOVA as VA. The DMA hardware must use the appropriate IOMMU stream IDs when initiating the DMA transfers. For example, in the use case shown in the diagram, dmadev-1 and dmadev-2 would join an access group managed by the kernel DMA controller driver. This controller driver will configure the access group on the DMA hardware, enabling the hardware to select the correct stream IDs for read/write operations. New rte_dma APIs could be introduced to join or leave the access group or to query the access group details. Additionally, a secure token mechanism (similar to vfio-pci token) can be implemented to validate any dmadev attempting to join the access group.<o:p></o:p> <o:p> </o:p> Regards.<o:p></o:p> <o:p> </o:p> <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: fengchengwen <fengchengwen@huawei.com> Sent: Tuesday, July 15, 2025 6:29 AM To: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org; Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; kevin.laatz@intel.com; bruce.richardson@intel.com; mb@smartsharesystems.com Cc: Jerin Jacob <jerinj@marvell.com>; thomas@monjalon.net Subject: [EXTERNAL] Re: [PATCH v0 1/1] doc: announce inter-device DMA capability support in dmadev<o:p></o:p> </div> </div> <o:p> </o:p> <div> Hi Vamsi, From the commit log, I guess this commit mainly want to meet following case: --------------- ---------------- | Container | | VirtMachine | | | | | | dmadev-1 | | dmadev2 | --------------- ---------------- | | ------------------------------<o:p></o:p> </div> <div> ZjQcmQRYFpfptBannerStart<o:p></o:p> </div> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%;border-radius:4px"> <tbody> <tr> <td style="padding:12.0pt 0in 12.0pt 0in"> <table class="MsoNormalTable" border="1" cellspacing="0" cellpadding="0" width="100%" style="width:100.0%;background:#D2D0D0;border:none;border-top:solid #8D8C8C 3.0pt"> <tbody> <tr> <td valign="top" style="border:none;padding:0in 7.5pt 3.75pt 4.5pt"> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left"> <tbody> <tr> <td style="padding:3.0pt 6.0pt 3.0pt 6.0pt"> Prioritize security for external emails: <o:p></o:p> </td> </tr> <tr> <td style="padding:3.0pt 6.0pt 3.0pt 6.0pt"> Confirm sender and content safety before clicking links or opening attachments <o:p></o:p> </td> </tr> </tbody> </table> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="right"> <tbody> <tr> <td style="padding:3.0pt 0in 3.0pt 0in"> <a href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!tg3ZldV0Yr_wdSwWmT2aDdKMi-4rn2z58vFaxwfOeocS1P19w1BeRdyGs5sjnhV2rU_6m8MOWj4KFbuXKkKJIvcqwWD2WEwJW_0$" target="_blank"> Report Suspicious </a> ‌ <o:p></o:p> </td> </tr> </tbody> </table> </td> </tr> </tbody> </table> </td> </tr> </tbody> </table> <div> ZjQcmQRYFpfptBannerEnd<o:p></o:p> </div> <div> <pre style="white-space:pre-wrap">Hi Vamsi,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>From the commit log, I guess this commit mainly want to meet following case:<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre> --------------- ----------------<o:p></o:p></pre> <pre> | Container | | VirtMachine |<o:p></o:p></pre> <pre> | | | |<o:p></o:p></pre> <pre> | dmadev-1 | | dmadev2 |<o:p></o:p></pre> <pre> --------------- ----------------<o:p></o:p></pre> <pre> | |<o:p></o:p></pre> <pre> ------------------------------<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>App run in the container could launch DMA transfer from local buffer to the VirtMachine by config<o:p></o:p></pre> <pre>dmadev-1/2 (the dmadev-1/2 are passthrough to diffent OS domain).<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Could you explain how to use it from application perspective (for example address translation) and<o:p></o:p></pre> <pre>application & hardware restrictions?<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>BTW: In this case, there are two OS domain communication, and I remember there are also inter-process<o:p></o:p></pre> <pre>DMA RFC, so maybe we could design more generic solution if you provide more info.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Thanks<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>On 2025/7/10 16:51, Vamsi Krishna wrote:<o:p></o:p></pre> <pre>> From: Vamsi Attunuru <<a href="mailto:vattunuru@marvell.com">vattunuru@marvell.com</a>><o:p></o:p></pre> <pre>> <o:p></o:p></pre> <pre>> Modern DMA hardware supports data transfer between multiple<o:p></o:p></pre> <pre>> DMA devices, enabling data communication across isolated domains or<o:p></o:p></pre> <pre>> containers. To facilitate this, the ``dmadev`` library requires changes<o:p></o:p></pre> <pre>> to allow devices to register with or unregisters from DMA groups for<o:p></o:p></pre> <pre>> inter-device communication. This feature is planned for inclusion<o:p></o:p></pre> <pre>> in DPDK 25.11.<o:p></o:p></pre> <pre>> <o:p></o:p></pre> <pre>> Signed-off-by: Vamsi Attunuru <<a href="mailto:vattunuru@marvell.com">vattunuru@marvell.com</a>><o:p></o:p></pre> <pre>> ---<o:p></o:p></pre> <pre>> doc/guides/rel_notes/deprecation.rst | 7 +++++++<o:p></o:p></pre> <pre>> 1 file changed, 7 insertions(+)<o:p></o:p></pre> <pre>> <o:p></o:p></pre> <pre>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst<o:p></o:p></pre> <pre>> index e2d4125308..46836244dd 100644<o:p></o:p></pre> <pre>> --- a/doc/guides/rel_notes/deprecation.rst<o:p></o:p></pre> <pre>> +++ b/doc/guides/rel_notes/deprecation.rst<o:p></o:p></pre> <pre>> @@ -152,3 +152,10 @@ Deprecation Notices<o:p></o:p></pre> <pre>> * bus/vmbus: Starting DPDK 25.11, all the vmbus API defined in<o:p></o:p></pre> <pre>> ``drivers/bus/vmbus/rte_bus_vmbus.h`` will become internal to DPDK.<o:p></o:p></pre> <pre>> Those API functions are used internally by DPDK core and netvsc PMD.<o:p></o:p></pre> <pre>> +<o:p></o:p></pre> <pre>> +* dmadev: a new capability flag ``RTE_DMA_CAPA_INTER_DEV`` will be added<o:p></o:p></pre> <pre>> + to advertise DMA device's inter-device DMA copy capability. To enable<o:p></o:p></pre> <pre>> + this functionality, a few dmadev APIs will be added to configure the DMA<o:p></o:p></pre> <pre>> + access groups, facilitating coordinated data communication between devices.<o:p></o:p></pre> <pre>> + A new ``dev_idx`` field will be added to the ``struct rte_dma_vchan_conf``<o:p></o:p></pre> <pre>> + structure to configure a vchan for data transfers between any two DMA devices.<o:p></o:p></pre> <pre><o:p> </o:p></pre> </div> </div> </div> </body> </html>