Hi Feng, Anatoly, Gentle ping for below review.
>-----Original Message----- >From: Vamsi Krishna Attunuru >Sent: Monday, September 22, 2025 5:19 PM >To: fengchengwen <[email protected]>; [email protected]; >[email protected] >Cc: [email protected]; [email protected]; >[email protected]; [email protected]; >[email protected]; Jerin Jacob <[email protected]> >Subject: RE: [EXTERNAL] Re: [RFC] lib/dma: introduce inter-process and inter- >OS DMA > >Hi Feng, > >>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 ZjQcmQRYFpfptBannerStart Prioritize >>security for external >>emails: >>Confirm sender and content safety before clicking links or opening >>attachments <https://us-phishalarm- >>ewt.proofpoint.com/EWT/v1/CRVmXkqW!tg3T9Z- >>UaB9Q3kwcmX07bQhw79tV6mlwlrOb9n3vIajFjxJ5sRC- >>Nz7n4irgY7TdHyR9yFdqJLsDhQdEN-Kf3T4NpkFvRVx8_TE$> >>Report Suspicious >> >>ZjQcmQRYFpfptBannerEnd >>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. > >This new feature needs to be securely managed through control APIs. It >would be extremely helpful if the folks at Intel and you as well could provide >support or inputs on this. > >> >>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. > >The vchan mechanism extends support for any PMD that may require any >other additional metadata (pasid, streamID etc) --specific to certain >architectures. However, the flags field to be fully utilized, and may not >accommodate further extensions if vchan needs to carry more information. > >> >> I prefer reserved 16bit from flags (not 32bit because it seem has no >>such requirement). > >16bits for both handles may be too limiting , especially if PMD requires a >larger >identifier in the future. >> >>[1] https://urldefense.proofpoint.com/v2/url?u=https- >>3A__mails.dpdk.org_archives_dev_2023- >>2DAugust_274590.html&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=WllrY >a >>umVkxaWjgKto6E_rtDQshhIhik2jkvzFyRhW8&m=luChQIFb4mhp46WDuPsT- >>lWtl6PWi3-9eUETNB3QKNP7xpKB6XWHmzEjx2SA- >>oXi&s=x2bfetryux8bDrWpG2KnB9Df4abCAQnSUy2CEpUTDtA&e= >> >>Thanks >> >>On 9/1/2025 8:33 PM, Vamsi Krishna wrote: >>> From: Vamsi Attunuru <[email protected]> >>> >>> 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 <[email protected]> >>> --- >>> 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(+) >>> >> >>...
