DPDK patches and discussions
 help / color / mirror / Atom feed
From: fengchengwen <fengchengwen@huawei.com>
To: Vamsi Krishna <vattunuru@marvell.com>, <dev@dpdk.org>
Cc: <thomas@monjalon.net>, <bruce.richardson@intel.com>,
	<vladimir.medvedkin@intel.com>, <anatoly.burakov@intel.com>,
	<kevin.laatz@intel.com>, <jerinj@marvell.com>
Subject: Re: [RFC] lib/dma: introduce inter-process and inter-OS DMA
Date: Fri, 19 Sep 2025 17:02:41 +0800	[thread overview]
Message-ID: <c366cdab-1538-4f70-8854-38f099b8990a@huawei.com> (raw)
In-Reply-To: <20250901123341.2665186-1-vattunuru@marvell.com>

Hi Vamsi,

This commit change is more than discussed, it add control API which for group management.

1. Control API: I check this commit and Intel commit [1], it seem has a quite difference.
   I hope Intel guys can express views. I prefer not add this part if no response.

2. Data API: this commit provide two way (vchan and flags) to use this feature, I'd rather
   stick to one, that way, so the app won't go haywire.

   The vchan scheme seems inflexible. If you want to update communication objects frequently
   during operation, the vchan needs to be recreated.

   I prefer reserved 16bit from flags (not 32bit because it seem has no such requirement).

[1] https://mails.dpdk.org/archives/dev/2023-August/274590.html

Thanks

On 9/1/2025 8:33 PM, Vamsi Krishna wrote:
> From: Vamsi Attunuru <vattunuru@marvell.com>
> 
> Modern DMA hardware supports data transfers between multiple DMA
> devices, facilitating data communication across isolated domains,
> containers, or operating systems. These DMA transfers function as
> standard memory-to-memory operations, but with source or destination
> addresses residing in different process or OS address space. The
> exchange of these addresses between processes is handled through
> private driver mechanism, which are beyond the scope of this
> specification change.
> 
> This commit introduces new capability flags to advertise driver support
> for inter-process or inter-OS DMA transfers. It provides two mechanisms
> for specifying source and destination handlers: either through the vchan
> configuration or via the flags parameter in DMA enqueue APIs. This commit
> also adds a controller ID field to specify the device hierarchy details
> when applicable.
> 
> To ensure secure and controlled DMA transfers, this commit adds a set
> of APIs for creating and managing access groups. Devices can create or
> join an access group using token-based authentication, and only devices
> within the same group are permitted to perform DMA transfers across
> processes or OS domains. This approach enhances security and flexibility
> for advanced DMA use cases in multi-tenant or virtualized environments.
> 
> The following flow demonstrates how two processes (a group creator and a
> group joiner) use the DMA access group APIs to securely set up and
> manage inter-process DMA transfers:
> 
> 1) Process 1 (Group Creator):
>    Calls rte_dma_access_group_create(group_token, &group_id) to create a
>    new access group.
>    Shares group_id and group_token with Process 2 via IPC.
> 2) Process 2 (Group Joiner):
>    Receives group_id and group_token from Process 1.
>    Calls rte_dma_access_group_join(group_id, group_token) to join the
>    group.
> 3) Both Processes:
>    Use rte_dma_access_group_size_get() to check the number of devices in
>    the group.
>    Use rte_dma_access_group_get() to retrieve the group table and
>    handler information.
> 
>    Perform DMA transfers as needed.
> 
> 4) Process 2 (when done):
>    Calls rte_dma_access_group_leave(group_id) to leave the group.
> 5) Process 1:
>    Receives RTE_DMA_EVENT_ACCESS_TABLE_UPDATE to be notified of group
>    changes.
>    Uses rte_dma_access_group_size_get() to confirm the group size.
> 
> This flow ensures only authenticated and authorized devices can
> participate in inter-process or inter-OS DMA transfers, enhancing
> security and isolation.
> 
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> ---
>  lib/dmadev/rte_dmadev.c       | 320 ++++++++++++++++++++++++++++++++++
>  lib/dmadev/rte_dmadev.h       | 255 +++++++++++++++++++++++++++
>  lib/dmadev/rte_dmadev_pmd.h   |  48 +++++
>  lib/dmadev/rte_dmadev_trace.h |  51 ++++++
>  4 files changed, 674 insertions(+)
> 

...


      parent reply	other threads:[~2025-09-19  9:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-01 12:33 Vamsi Krishna
2025-09-18 11:06 ` Vamsi Krishna Attunuru
2025-09-19  9:02 ` fengchengwen [this message]

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=c366cdab-1538-4f70-8854-38f099b8990a@huawei.com \
    --to=fengchengwen@huawei.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=kevin.laatz@intel.com \
    --cc=thomas@monjalon.net \
    --cc=vattunuru@marvell.com \
    --cc=vladimir.medvedkin@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).