Publish-subscribe interface

Abstract

A publish-subscribe interface is disclosed. In one embodiment, a data processing unit (DPU) includes a host interface to receive a generic publish-subscribe (Pub / Sub) call from a host device, at least one processing core to perform an orchestration function to select a particular Pub / Sub service based on the generic Pub / Sub call and a conversion layer to convert the generic Pub / Sub call to a particular Pub / Sub call compatible with the selected particular Pub / Sub service, and a forwarding interface to provide the converted particular Pub / Sub call to the selected particular Pub / Sub service.

Description

Technical Field

[0001] This disclosure relates to computer systems, specifically but not limited to publish-subscribe systems. Background Technology

[0002] Publish-subscribe (pub / sub) systems have become an integral part of modern distributed computing architectures. These systems provide a messaging paradigm that allows decoupled communication between publishers who produce and send messages and subscribers who receive and process messages of interest. pub / sub systems are widely used in a variety of applications, including real-time data processing, event-driven architectures, and Internet of Things (IoT) scenarios.

[0003] In a typical pub / sub system, publishers and subscribers are unaware of each other's existence. Instead, they interact through an intermediary component often referred to as a broker. Publishers send messages about specific topics, while subscribers express interest in one or more topics. The broker is responsible for receiving messages from publishers, managing subscriptions, and delivering messages to the appropriate subscribers. Summary of the Invention

[0004] According to embodiments of this disclosure, a data processing unit (DPU) is provided, comprising: a host interface for receiving a generic publish-subscribe (Pub / Sub) call from a host device; at least one processing core for performing: an orchestration function to select a specific pub / sub service based on the generic pub / sub call, and a transformation layer to transform the generic pub / sub call into a specific pub / sub call compatible with the selected specific pub / sub service; and a forwarding interface for providing the transformed specific pub / sub call to the selected specific pub / sub service.

[0005] Furthermore, according to embodiments of the present invention, a particular pub / sub service includes at least one of the following: a proxy-based pub / sub service or a proxyless pub / sub service.

[0006] Furthermore, according to embodiments of this disclosure, a general pub / sub call includes publishing a message or a subscription request.

[0007] Additionally, according to embodiments of this disclosure, the orchestration function is used to maintain a mapping between topics and different pub / sub services.

[0008] Furthermore, according to embodiments of this disclosure, the orchestration function is used to select a specific pub / sub service based on the topic associated with a general pub / sub call.

[0009] Furthermore, according to embodiments of this disclosure, at least one processing core is used to execute a paravirtualized pub / sub backend to interface with a paravirtualized pub / sub driver frontend running on the host device.

[0010] Furthermore, according to embodiments of this disclosure, the quasi-virtualized pub / sub backend includes multiple backend transformation functions of the transformation layer, each backend transformation function corresponding to a different pub / sub service.

[0011] Additionally, according to embodiments of this disclosure, the general pub / sub call is based on Remote Direct Memory Operation (RDMO) pub / sub commands.

[0012] Furthermore, according to embodiments of this disclosure, the orchestration function is configured to receive RDMO notifications from the host device, read RDMO pub / sub commands from a work queue stored in the host memory in response to receiving the RDMO notifications, and derive generic pub / sub calls from the read RDMO pub / sub commands.

[0013] Furthermore, according to embodiments of this disclosure, the conversion layer includes multiple conversion functions for converting generic pub / sub calls into specific pub / sub calls compatible with the corresponding pub / sub service.

[0014] Furthermore, according to embodiments of this disclosure, at least one processing core is used to perform security functions to filter or block pub / sub calls based on predefined criteria without notifying the host device.

[0015] According to another embodiment of this disclosure, a system is also provided, comprising: a host device for generating generic publish-subscribe (Pub / Sub) calls and a data processing unit (DPU) coupled to the host device, the DPU comprising: a host interface for receiving generic pub / sub calls from the host device; at least one processing core for performing: an orchestration function to select a specific pub / sub service based on the generic pub / sub calls; a transformation layer to transform the generic pub / sub calls into specific pub / sub calls compatible with the selected specific pub / sub service; and a forwarding interface for providing the transformed specific pub / sub calls to the selected specific pub / sub service.

[0016] Additionally, according to embodiments of the present invention, a particular pub / sub service includes at least one of the following: a proxy-based pub / sub service or a proxy-free pub / sub service.

[0017] Furthermore, according to embodiments of this disclosure, a general pub / sub call includes publishing a message or a subscription request.

[0018] Furthermore, according to embodiments of this disclosure, the orchestration function is used to maintain the mapping between topics and different pub / sub services.

[0019] Furthermore, according to embodiments of this disclosure, the orchestration function is used to select a specific pub / sub service based on the topic associated with a general pub / sub call.

[0020] Additionally, according to embodiments of this disclosure, the host device is used to execute a paravirtualized pub / sub driver frontend, and at least one processing core of the DPU is used to execute a paravirtualized pub / sub backend to interface with the paravirtualized pub / sub driver frontend running on the host device.

[0021] Furthermore, according to embodiments of this disclosure, the quasi-virtualized pub / sub backend includes multiple backend transformation functions of the transformation layer, each backend transformation function corresponding to a different pub / sub service.

[0022] Furthermore, according to embodiments of this disclosure, a generic pub / sub call is included in a Remote Direct Memory Operation (RDMO) pub / sub command.

[0023] Furthermore, according to embodiments of this disclosure, the host device is configured to: generate RDMO pub / sub commands, write the RDMO pub / sub commands into a work queue stored in the host memory, and send an RDMO notification to the DPU, the RDMO notification informing the DPU that the RDMO pub / sub commands are in the work queue; and the orchestration function is configured to: receive RDMO notifications from the host device, read RDMO pub / sub commands from the work queue in response to receiving the RDMO notifications, and derive a generic pub / sub call from the read RDMO pub / sub commands.

[0024] Additionally, according to embodiments of this disclosure, the conversion layer includes multiple conversion functions for converting generic pub / sub calls into specific pub / sub calls compatible with the corresponding pub / sub service.

[0025] Furthermore, according to embodiments of this disclosure, at least one processing core is used to perform security functions to filter or block pub / sub calls based on predefined criteria without notifying the host device.

[0026] According to another embodiment of this disclosure, a method is also provided, comprising: receiving a generic publish-subscribe (Pub / Sub) call from a host device; selecting a specific pub / sub service based on the generic pub / sub call; converting the generic pub / sub call into a specific pub / sub call compatible with the selected specific pub / sub service; and providing the converted specific pub / sub call to the selected specific pub / sub service. Attached Figure Description

[0027] This disclosure will be understood in conjunction with the accompanying drawings and the following detailed description, wherein:

[0028] Figure 1 This is a partial block diagram view of a pub / sub system with multiple agent and agentless services constructed and operated according to embodiments of this disclosure;

[0029] Figure 2 It is used for Figure 1 A block diagram view of the system's paravirtualized pub / sub subsystem;

[0030] Figure 3A and Figure 3B It includes Figure 2 A flowchart of the steps in the operation method of the paravirtualized pub / sub subsystem;

[0031] Figure 4 It is used for Figure 1 A block diagram view of the RDMO pub / sub subsystem of the system;

[0032] Figure 5A and Figure 5B It includes Figure 4 A flowchart of the steps in the operation method of the RDMO pub / sub subsystem; and

[0033] Figure 6 This is a schematic diagram illustrating a block diagram of a computing system (e.g., a data center or a high-performance computing (HPC) cluster) according to embodiments of the present disclosure. Detailed Implementation

[0034] Overview of Example Implementations

[0035] With the increasing adoption of pub / sub systems, various implementations and services have emerged, each with its own set of APIs, protocols, and characteristics. This diversity presents challenges to the interoperability and portability of applications across different pub / sub environments. Developers often find themselves tightly coupled with specific pub / sub implementations, making it difficult to switch between services or utilize multiple pub / sub systems simultaneously.

[0036] The increasing complexity of distributed systems has highlighted the need for more flexible and efficient pub / sub architectures. Traditional proxy-based systems may introduce latency and scalability issues in certain scenarios, leading to the development of agentless pub / sub implementations. However, the coexistence of proxy-based and agentless systems further complicates the situation for application developers and system architects.

[0037] As organizations adopt multi-cloud strategies and hybrid infrastructures, the ability to seamlessly integrate and manage pub / sub communications across different environments becomes crucial. This integration challenge goes beyond simply connecting different pub / sub systems; it also involves addressing security, performance, and operational issues that arise in heterogeneous deployments.

[0038] The development of hardware acceleration technologies, such as data processing units (DPUs), has provided new opportunities for optimizing pub / sub systems. These dedicated processors offer the potential to offload and accelerate pub / sub operations, thereby reducing latency and improving overall system efficiency. However, leveraging these capabilities in a way that maintains the abstraction and flexibility of pub / sub systems remains an area of ​​active research and development.

[0039] As the pub / sub systems landscape continues to evolve, there is a growing demand for solutions that bridge the gaps between different implementations, offer greater flexibility in deployment options, and leverage emerging hardware technologies. Addressing these challenges may lead to more robust, scalable, and efficient pub / sub architectures that better meet the needs of modern distributed applications.

[0040] Therefore, embodiments of this disclosure address at least some of these challenges by providing a publish / subscribe orchestration and translation system implemented using a data processing unit (DPU). This system addresses the challenges of interoperability and flexibility in pub / sub communication across different environments. The DPU acts as an intermediary layer between one or more host devices that generate generic pub / sub calls and various specific pub / sub services.

[0041] Generic pub / sub calls can be generated by pub / sub applications running on the host device. A pub / sub application can be a publishing application and / or a subscribing application. A pub / sub call can be a publish call or a subscribe call. Similarly, any reference to pub / sub in this document can be understood as a reference to publishing and / or subscribing.

[0042] The DPU has a host interface for receiving generic pub / sub calls from one or more host devices, an orchestration function for selecting appropriate specific pub / sub services based on the received generic pub / sub calls, a transformation layer for converting generic pub / sub calls into specific pub / sub calls compatible with the selected services, and a forwarding interface for transmitting the transformed calls to the selected pub / sub server (e.g., a proxy).

[0043] The orchestration feature maintains a mapping between topics and services, allowing it to select the appropriate pub / sub service for each invocation. The system supports both proxy-based and proxyless pub / sub services, enhancing its flexibility and applicability across different architectures.

[0044] To facilitate efficient communication from one or more host devices to the DPU, one or more host devices can run a paravirtualized pub / sub driver frontend that interfaces with a paravirtualized backend running on the DPU. The backend can include multiple translation functions, each corresponding to a different pub / sub service (e.g., a proxy), thereby facilitating system updates and maintenance.

[0045] This disclosure also supports Remote Direct Memory Operations (RDMO) pub / sub commands, thereby improving performance in appropriate scenarios. When using RDMO pub / sub commands, the orchestration function can receive RDMO pub / sub notifications from the host device, read RDMO pub / sub commands from the work queue in the host memory, and derive generic pub / sub calls from these commands.

[0046] Additionally, the DPU can be combined with security features to filter or block pub / sub calls based on predefined criteria, thereby enhancing system security without notifying the host device.

[0047] This comprehensive approach allows for the use of standardized pub / sub interfaces, while the DPU manages the complexity of interfaces with various pub / sub implementations, thereby enhancing interoperability, portability, and scalability across different pub / sub environments, including multi-cloud and hybrid infrastructures.

[0048] System Description

[0049] Now, for reference Figure 1 ,Should Figure 1 This is a partial block diagram view of a pub / sub system 10 constructed and operated according to embodiments of the present disclosure, having multiple agents 20 and agentless services 20-3. Figure 1 The illustration shows a publish-subscribe (pub / sub) system 10 comprising multiple host devices 12 and a data processing unit (DPU) 14, which interact with both proxy-based pub / sub services and proxyless pub / sub services.

[0050] A Data Processing Unit (DPU) is a dedicated processor designed to handle data-centric tasks, thereby offloading and accelerating data processing operations from the Central Processing Unit (CPU). DPUs are typically used in high-performance computing environments, data centers, and network infrastructure to improve efficiency and performance. They are equipped with multiple processing cores, memory, and network interfaces, enabling them to manage tasks such as data movement, security, and network traffic management. In the context of publish-subscribe (pub / sub) systems, a DPU can serve as an intermediary layer between host devices that generate generic pub / sub calls and various specific pub / sub services, thus handling the complexity of interfacing with diverse pub / sub implementations.

[0051] In the context of publish / subscribe (Pub / Sub) systems, a broker service refers to an intermediary component that facilitates communication between publishers and subscribers. In a broker-based pub / sub system, publishers send messages to a broker, which then routes these messages to the appropriate subscribers based on their subscriptions. The broker manages the distribution of messages, ensuring that each subscriber receives the messages they are interested in. This approach decouples publishers and subscribers, allowing them to operate independently without knowing of each other's existence. Broker services handle tasks such as message filtering, delivery, and persistence, thus providing a centralized point for managing pub / sub communication.

[0052] In the context of publish-subscribe (Pub / Sub) systems, agentless services refer to pub / sub implementations that operate without using an intermediary component called a proxy. In agentless pub / sub systems, publishers send messages directly to subscribers without routing through a central proxy. This reduces latency and improves scalability by eliminating the need for intermediaries to manage message distribution. This approach allows for more direct and efficient communication between publishers and subscribers.

[0053] The pub / sub system 10 includes several host devices 12 (i.e., host devices 12-1, 12-2, 12-3, and 12-4). Host devices 12-1 and 12-2 are equipped with publisher applications 16 that generate messages on specific topics. These messages are then sent to their respective DPUs 14-1 and 14-2 for further processing.

[0054] Host device 12-1 running publisher application 16 generates message 22-1 about topic A. Message 22-1 is sent to DPU 14-1, which processes message 22-1 and forwards it to agent X (reference numeral 20-1). Similarly, host device 12-2 running publisher application 16 generates message 22-2 about topic B. Message 22-2 is sent to DPU 14-2, which processes it and forwards it to agent Y (reference numeral 20-2). Additionally, another message 22-3 about topic C is generated by publisher application 16 on host device 12-1 and sent to agentless service 20-3.

[0055] On the subscriber side, host devices 12-3 and 12-4 are equipped with subscriber applications 18. These applications 18 express interest in a specific topic through subscription requests 24. Host device 12-3 running subscriber application 18 subscribes to topic C using request 24-3. This subscription request 24-3 is processed by DPU 14-3 and delivered to agentless service 20-3, which ensures that messages about topic C are delivered to the subscriber application running on host device 12-3. Additionally, there is a subscription request 24-2 for topic B. This subscription request 24-2 is processed by DPU 14-3 and delivered to agent Y (reference numeral 20-2), which ensures that messages about topic B are delivered to the subscriber application running on host device 12-3.

[0056] The host device 12-4, which is also running subscriber application 18, subscribes to topic A via request 24-1. This subscription request 24-1 is processed by DPU 14-4 and sent to agent X (reference numeral 24-1), which ensures that messages about topic A are delivered to the subscriber application running on host device 12-4.

[0057] The pub / sub system 10 supports both proxy-based and proxyless pub / sub services, providing a flexible and efficient architecture for managing pub / sub communication across different environments. By leveraging the capabilities of the DPU 14, the system can handle the complexity of interfaces with various pub / sub services, ensuring seamless interoperability and scalability.

[0058] Now, for reference Figure 2 ,Should Figure 2 It is used for Figure 1 A block diagram view of the paravirtualized pub / sub subsystem 200 of system 10.

[0059] The paravirtualized pub / sub subsystem 200 operates within the pub / sub system 10, thereby facilitating communication between one or more host devices and various pub / sub services. The paravirtualized pub / sub subsystem 200 includes several components that work together to manage and translate pub / sub calls.

[0060] Paravirtualization refers to a virtualization technology in which a guest operating system (OS) is aware of the virtualized environment and interacts with the hypervisor through a dedicated interface. This approach allows for more efficient communication and resource management between the guest OS and the hypervisor because the guest OS can make optimized calls to the hypervisor, thereby reducing the overhead typically associated with full virtualization. In the context of this disclosure, a paravirtualized pub / sub driver frontend running on the host interface with a paravirtualized backend running on the DPU, thereby facilitating efficient communication and translation of pub / sub calls.

[0061] Subsystem 200 includes host device 202, which includes processor 206. Processor 206 is configured to execute a generic pub / sub application 208, which is configured to generate generic pub / sub calls 210. Depending on the specific use case, generic pub / sub application 208 may be a publisher application or a subscriber application. Generic pub / sub calls 210 may include publish messages or subscription requests.

[0062] Processor 206 is configured to execute a paravirtualized pub / sub driver 212, which is configured to receive generic pub / sub calls 210 from a generic pub / sub application 208 running on host device 202. The paravirtualized pub / sub driver 212 acts as a front-end driver, thereby facilitating communication between host device 202 and DPU 220.

[0063] Subsystem 200 also includes a DPU 220 coupled to host device 202 via host interface 224. DPU 220 includes several sub-components, including one or more processing cores 222, host interface 224, and forwarding interface 226. Host interface 224 is configured to receive generic pub / sub calls 210 from a paravirtualized pub / sub driver 212 running on host device 202. One or more processing cores 222 are configured to perform orchestration functions 228 and a translation layer 230.

[0064] The orchestration function 228 within the DPU 220 is configured to select a specific pub / sub service based on the received general pub / sub call 210. The specific pub / sub service can be a proxy-based pub / sub service (such as proxy X (reference numeral 20-1) and proxy Y (reference numeral 20-2)) or a proxyless pub / sub service 20-3. The orchestration function 228 is configured to maintain a mapping between topics and different pub / sub services (i.e., which services manage which topics), thereby allowing the selection of an appropriate pub / sub server for each call. The orchestration function 228 is configured to select between proxy-based pub / sub services (such as proxy X (reference numeral 20-1) and proxy Y (reference numeral 20-2)) and the proxyless pub / sub service 20-3.

[0065] The translation layer 230 within the DPU 220 is configured to translate generic pub / sub calls 210 into pub / sub calls compatible with a selected specific pub / sub service. The translation layer 230 includes multiple translation functions, such as translation function X (reference numeral 232-1), translation function Y (reference numeral 232-2), and translation function BL (reference numeral 232-3), where BL stands for no agent. Each translation function corresponds to a different pub / sub service, thereby ensuring that the translated calls are compatible with the selected pub / sub service.

[0066] The forwarding interface 226 within the DPU 220 is configured to provide translated, specific pub / sub calls to a selected specific pub / sub service. Forwarding interface 226 ensures that the translated calls are delivered to the appropriate pub / sub service, regardless of whether the service is proxy-based or proxyless.

[0067] The paravirtualized pub / sub subsystem 200 supports both agent-based and agentless pub / sub services, enhancing flexibility and applicability across different architectures. Subsystem 200 can handle publish messages and subscribe requests, ensuring seamless interoperability and scalability across different pub / sub environments.

[0068] The paravirtualized pub / sub subsystem 200 also includes security function 236 within the DPU 220. Security function 236 is configured to filter or block pub / sub calls based on predefined criteria without notifying the host device 202. This enhances system security by preventing the processing of unauthorized or malicious pub / sub calls.

[0069] The paravirtualized pub / sub subsystem 200 interfaces with a paravirtualized backend and a paravirtualized pub / sub driver 212 running on host device 202, where host device 202 treats DPU 220 as a virtual pub / sub device. These backends include multiple backend translation functions of translation layer 230, each corresponding to a different pub / sub service. This configuration allows for easy system updates and maintenance, ensuring the system can adapt to changes in pub / sub services and protocols.

[0070] The paravirtualized pub / sub subsystem 200 provides a comprehensive solution for managing pub / sub communications across different environments. By leveraging the capabilities of the DPU 220, the system can handle the complexity of interfaces with various pub / sub services, ensuring seamless interoperability, portability, and scalability.

[0071] Now, for reference Figure 3A and Figure 3B They include Figure 2 The flowcharts 300 and 320 show the steps in the operation method of the paravirtualized pub / sub subsystem. Figure 3A and Figure 3B An embodiment of a method for operating a quasi-virtualized publish-subscribe (pub / sub) subsystem is illustrated. Methods 300 and 320 can be implemented via... Figure 2 The paravirtualized pub / sub subsystem 200 described in the document is implemented.

[0072] exist Figure 3A At step 302, processor 206 executes a generic pub / sub application 208 and a paravirtualized pub / sub driver 212 on host device 202. Generic pub / sub application 208 generates generic pub / sub calls, while paravirtualized pub / sub driver 212 facilitates communication between host device 202 and DPU 220.

[0073] At step 304, the generic pub / sub application 208 generates a generic pub / sub call 210. Depending on the specific use case of the generic pub / sub application 208, this call can be a publish message or a subscribe request.

[0074] At step 306, the paravirtualization pub / sub driver 212 provides a generic pub / sub call 210 to the host interface 224 of the DPU 220 for further processing.

[0075] exist Figure 3B At step 322, orchestration function 228 maintains a mapping between topics and different pub / sub services. This mapping allows orchestration function 228 to select the appropriate pub / sub service for each generic pub / sub call 210 based on the relevant topic.

[0076] At step 324, host interface 224 receives generic pub / sub call 210 from paravirtualization pub / sub driver 212.

[0077] At step 326, orchestration function 228 selects a specific pub / sub service based on the received general pub / sub call 210. The selection is made using the mapping maintained in step 322, thereby ensuring that the call is directed to the appropriate pub / sub service.

[0078] At step 328, the relevant conversion functions of conversion layer 230 convert the general pub / sub call 210 into a specific pub / sub call compatible with the selected specific pub / sub service. Conversion layer 230 includes multiple conversion functions, such as conversion function X (reference numeral 232-1), conversion function Y (reference numeral 232-2), and conversion function BL (reference numeral 232-3).

[0079] At step 330, security function 236 performs security checks on a specific pub / sub call and filters or blocks the specific pub / sub call if one or more security criteria are not met (e.g., without notifying the host device). If the specific pub / sub call is not blocked, the method continues to step 332. Security checks may include: enforcing privileged access to certain topics for publish or subscribe calls, enforcing privileged access to specific messages containing sensitive data, anonymizing sensitive data in messages, or preventing the processing of unauthorized or malicious pub / sub calls.

[0080] At step 332, forwarding interface 226 provides the translated specific pub / sub call to the selected specific pub / sub service (i.e., the selected proxy or no proxy). Forwarding interface 226 ensures that the translated call is forwarded to the appropriate pub / sub service for further processing, whether it is proxy X, proxy Y, or no proxy.

[0081] Now, for reference Figure 4 ,Should Figure 4It is used for Figure 1 The diagram shows a block diagram of the RDMO pub / sub subsystem 400 of the system. The RDMO pub / sub subsystem 400 operates within the pub / sub system 10, thereby facilitating communication between one or more host devices and various pub / sub services. The RDMO pub / sub subsystem 400 includes several components that work together to manage and translate pub / sub calls.

[0082] Subsystem 400 includes host device 402, which includes processor 406 configured to execute a generic pub / sub application 408 that generates generic pub / sub calls, including generic pub / sub calls 410. Depending on the specific use case, generic pub / sub application 408 may be a publisher application or a subscriber application. Generic pub / sub calls 410 may include publish messages or subscription requests. Host device 402 also includes memory 404.

[0083] Processor 406 is configured to execute RDMO pub / sub driver 412. RDMO pub / sub driver 414 is configured to generate RDMO pub / sub command 414 from generic pub / sub call 410 and add RDMO pub / sub command 414 as a work queue entry (WQE) to work queue 416, which is stored in memory 404 of host device 402. RDMO pub / sub command 414 includes generic pub / sub call 410 or a link to generic pub / sub call 410.

[0084] The RDMO pub / sub driver 412 is configured to generate RDMO notification 418 and provide RDMO notification 418 to orchestration function 428 via host interface 424 of DPU 420 to notify orchestration function 428 of RDMO pub / sub command 414 waiting in work queue 416.

[0085] Subsystem 400 also includes a DPU 420 coupled to host device 402 via host interface 424. DPU 420 includes several sub-components, including one or more processing cores 422, host interface 424, and forwarding interface 426. Host interface 424 is configured to receive RDMO notification 418 from RDMO pub / sub driver 412 and provide that RDMO notification 418 to orchestration function 428. One or more processing cores 422 are configured to perform orchestration function 428 and translation layer 430.

[0086] The orchestration function 428 is configured to receive RDMO notification 418 (from host device 402) and, in response to receiving RDMO notification 418, retrieve RDMO pub / sub commands 414 from work queue 416, extract generic pub / sub calls 410 from RDMO pub / sub commands 414, and select a specific pub / sub service based on the extracted generic pub / sub calls 410. The specific pub / sub service can be a proxy-based pub / sub service (such as proxy X (reference numeral 20-1) and proxy Y (reference numeral 20-2)) or a proxyless pub / sub service 20-3.

[0087] Orchestration feature 428 maintains a mapping between topics and different pub / sub services, allowing the selection of the appropriate pub / sub service for each call. Figure 4 In the example, orchestration function 428 can choose between proxy-based pub / sub services (such as proxy X (reference numeral 20-1) and proxy Y (reference numeral 20-2)) and proxy-free pub / sub services 20-3.

[0088] The conversion layer 430 within the DPU 420 converts the generic pub / sub call 410 into a specific pub / sub call compatible with the selected specific pub / sub service. The conversion layer 430 includes multiple conversion functions, such as conversion function X (reference numeral 432-1), conversion function Y (reference numeral 432-2), and conversion function BL (reference numeral 432-3). Each conversion function corresponds to a different pub / sub service, thereby ensuring that the converted pub / sub call is compatible with the selected service.

[0089] Forwarding interface 426 is configured to provide translated, specific pub / sub calls to a selected specific pub / sub service. Forwarding interface 426 ensures that translated calls are delivered to the appropriate pub / sub service, whether the service is a proxy-based service or a proxyless service.

[0090] The RDMO pub / sub subsystem 400 supports both proxy-based and proxyless pub / sub services, enhancing flexibility and applicability across different architectures. The system can handle publish messages and subscribe requests, ensuring seamless interoperability and scalability across various pub / sub environments.

[0091] The RDMO pub / sub subsystem 400 also includes security function 436 within the DPU 420. Security function 436 is configured to filter or block pub / sub calls based on predefined criteria without notifying the host device 402. This enhances system security by preventing the processing of unauthorized or malicious pub / sub calls.

[0092] The RDMO pub / sub subsystem 400 provides a comprehensive solution for managing pub / sub communications across different environments. By leveraging the capabilities of the DPU 420, the system can handle the complexity of interfaces with various pub / sub services, ensuring seamless interoperability, portability, and scalability.

[0093] Now, for reference Figure 5A and Figure 5B They include Figure 4 Flowcharts 500 and 520 show the steps in the operation method of the RDMO pub / sub subsystem 400. Figure 5A In flowchart 500, the process begins at step 502, where processor 406 executes a generic pub / sub application 408 and an RDMO pub / sub driver 412 on host device 402. Generic pub / sub application 408 generates generic pub / sub calls 410, while RDMO pub / sub driver 412 facilitates communication between host device 402 and DPU 420.

[0094] At step 504, the generic pub / sub application 408 generates a generic pub / sub call 410. Depending on the specific use case of the generic pub / sub application 408, this call can be a publish message or a subscribe request.

[0095] At step 506, the RDMO pub / sub driver 412 generates an RDMO pub / sub command 414. At step 508, the RDMO pub / sub driver 412 adds the RDMO pub / sub command 414 as a WQE to the work queue 416.

[0096] At step 510, the RDMO pub / sub driver 412 generates an RDMO notification 418 provided to the orchestration function 428 via the host interface 424. This notification 418 informs the orchestration function 428 of the RDMO pub / sub command 414 waiting in the work queue 416.

[0097] exist Figure 5BIn flowchart 520, starting with step 522, the orchestration function 428 maintains a mapping between topics and different pub / sub services. This mapping allows the system to select the appropriate pub / sub service for each generic pub / sub call 410 based on the relevant topic.

[0098] At step 524, host interface 424 receives RDMO notification 418 from RDMO pub / sub driver 412. This notification informs orchestration function 428 of RDMO pub / sub commands 414 waiting in work queue 416.

[0099] At step 526, orchestration function 428 reads the RDMO pub / sub command 414 from work queue 416. Orchestration function 428 retrieves command 414 from queue 416 stored in host memory 404.

[0100] At step 528, orchestration function 428 derives a generic pub / sub call 410 from the read RDMO pub / sub command 414. This step involves extracting information from command 414 to generate the generic pub / sub call 410.

[0101] At step 530, orchestration function 428 selects a specific pub / sub service based on the received general pub / sub call 410. The selection is made using the mapping maintained in step 522, thereby ensuring that the call is directed to the appropriate pub / sub service.

[0102] At step 532, the conversion layer 430 converts the generic pub / sub call 410 into a pub / sub call compatible with the selected specific pub / sub service. The conversion layer 430 includes multiple conversion functions, such as conversion function X, conversion function Y, and conversion function BL.

[0103] At step 534, security function 436 performs security checks on a specific pub / sub call and filters or blocks the specific pub / sub call if one or more security criteria are not met (e.g., without notifying the host device). If the specific pub / sub call is not blocked, the method continues to step 536. Security checks may include: enforcing privileged access to certain topics for publish or subscribe calls, enforcing privileged access to specific messages containing sensitive data, anonymizing sensitive data in messages, or preventing the processing of unauthorized or malicious pub / sub calls.

[0104] At step 536, forwarding interface 426 provides the translated specific pub / sub call to the selected specific pub / sub service. Forwarding interface 426 ensures that the translated call is transmitted to the appropriate pub / sub service for further processing, whether it is proxy X, proxy Y, or no proxy.

[0105] Now, for reference Figure 6 ,Should Figure 6 This is a schematic block diagram illustrating a computing system 600 (e.g., a data center or high-performance computing (HPC) cluster) according to embodiments of the present disclosure. References above herein... Figures 1-5B The network devices 14, 220, and 420 described herein can be included in System 600 as one of the DPUs in System 600. (See the references above.) Figures 1-5B The described host devices 12, 202, and 402 can be included in system 600 as one of the processing devices 602 and 604.

[0106] According to at least one embodiment, system 600 includes multiple subsystems, such as multiple processing devices, multiple network devices, and multiple networks coupled to each other. The computing system 600 is designed to have multiple integrated circuits (referred to as processing devices), wherein each integrated circuit may include one or more CPUs and GPUs, thereby forming a robust and flexible architecture.

[0107] Various processing devices are interconnected via NVLink or other high-speed interconnects to enable high-speed communication between subsystems; and are also connected via NICs or DPUs to ensure efficient data transfer on computing system 600 and with one or more external networks 630, 636. In this example, system 600 includes a packet switch 648 that connects NIC / DPU 628 to network 630 and a packet switch 650 that connects NIC / DPU 632 to network 636.

[0108] Seamless data exchange and parallel processing are enabled through NVLink-coupled processing devices, thereby improving overall computing performance. The processing devices connect to multiple networks via one or more network interface cards (NICs) or DPUs, enabling the system to handle complex multi-network tasks with high bandwidth and low latency. This configuration is ideal for demanding applications requiring significant processing power, such as artificial intelligence (AI), machine learning (ML), and data-intensive computing, while ensuring robust connectivity and scalability across various networked environments. The integrated circuits of the computing system 600 may include one or more CPUs and one or more GPUs.

[0109] Figure 6An example architecture of a multi-GPU architecture is also shown. As shown in the figure, computing system 600 includes a processing device 602 with a multi-GPU architecture. Specifically, processing device 602 may be a system-on-a-chip and includes multiple subsystems such as CPU 606, GPU 608, and GPU 610. CPU 606 may be coupled to GPU 608 via die-to-die (D2D) or chip-to-chip (C2C) interconnects 612 (such as ground reference signaling interconnects (GRS interconnects)). CPU 606 may be coupled to GPU 610 via D2D or C2C interconnects 614. CPU 606 may also be coupled to GPU 608 and GPU 610 via PCIe interconnects.

[0110] The CPU 606 can be coupled to one or more NICs or DPUs, which in turn are coupled to one or more networks. For example, as Figure 6 As illustrated, CPU 606 is coupled to a first NIC / DPU 626, which is coupled to network 630. CPU 606 is also coupled to a second NIC / DPU 628, which is coupled to network 630 via switch 648. For example, NIC / DPU 626 and NIC / DPU 628 can be coupled to network 630 via Ethernet (ETH), NVLINK, or InfiniBand (IB) connections.

[0111] The computing system 600 also includes a processing device 604 with a multi-GPU architecture. Specifically, the processing device 604 includes multiple subsystems, including a CPU 616, a GPU 618, and a GPU 620. The CPU 616 can be coupled to the GPU 618 via a D2D or C2C interconnect 622. The CPU 616 can be coupled to the GPU 620 via a D2D or C2C interconnect 624. The CPU 616 can also be coupled to the GPU 618 and GPU 620 via a PCIe interconnect. The CPU 616 can be coupled to one or more NICs or DPUs, which in turn are coupled to one or more networks. For example, as... Figure 6 As illustrated, CPU 616 is coupled to a first NIC / DPU 632, which is coupled to network 636. CPU 616 is also coupled to a second NIC / DPU 634, which is coupled to network 636 via switch 650. NIC / DPU 632 and NIC / DPU 634 can be coupled to network 636 via Ethernet (ETH), NVLINK, or InfiniBand (IB) connections.

[0112] In at least one embodiment, processing device 602 and processing device 604 can communicate with each other via NIC / DPU 638 (such as via PCIe interconnect). Processing device 602 and processing device 604 can also communicate with each other via high-bandwidth communication interconnect 640 (such as NVLink interconnect or other high-speed interconnect). Figure 6 The packet switches in the diagram can include, for example, Nvidia Quantum-2 switches. The NIC / DPU in the diagram can include, for example, Nvidia Bluefield DPUs.

[0113] For clarity, the various features of this disclosure described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, for brevity, the various features of this disclosure described in the context of a single embodiment may also be provided separately or in any suitable sub-combination.

[0114] The embodiments described above are referenced by way of example, and this disclosure is not limited to the specific examples shown and described herein. Rather, the scope of this disclosure includes combinations and sub-combinations of the various features described herein, as well as variations and modifications that may occur to those skilled in the art upon reading the foregoing description and that are not disclosed in the prior art.

Claims

1. A data processing unit (DPU), comprising: The host interface is used to receive general publish-subscribe Pub / Sub calls from the host device; At least one processing core is used to execute: Orchestration functionality to select a specific pub / sub service based on the general pub / sub call; and A conversion layer is used to convert the generic pub / sub calls into pub / sub calls that are compatible with the selected specific pub / sub service; as well as A forwarding interface is used to provide the transformed specific pub / sub call to the selected specific pub / sub service.

2. The DPU of claim 1, wherein the specific pub / sub service includes at least one of the following: a proxy-based pub / sub service or a proxyless pub / sub service.

3. The DPU of claim 1, wherein the general pub / sub call includes a publish message or a subscribe request.

4. The DPU of claim 1, wherein the orchestration function is used to maintain the mapping between topics and different pub / sub services.

5. The DPU of claim 4, wherein the orchestration function is used to select the specific pub / sub service based on the topic associated with the general pub / sub call.

6. The DPU of claim 1, wherein the at least one processing core is configured to execute a paravirtualized pub / sub backend to interface with a paravirtualized pub / sub driver frontend running on the host device.

7. The DPU according to claim 6, wherein the paravirtualized pub / sub backend includes multiple backend conversion functions of the conversion layer, each backend conversion function corresponding to a different pub / sub service.

8. The DPU of claim 1, wherein the general pub / sub call is based on the Remote Direct Memory Operation (RDMO) pub / sub command.

9. The DPU of claim 8, wherein the orchestration function is used for: Receive RDMO notification from the host device; In response to receiving the RDMO notification, the RDMOpub / sub command is read from the work queue stored in the host memory; and The generic pub / sub call is derived from the read RDMO pub / sub command.

10. The DPU of claim 1, wherein the conversion layer includes a plurality of conversion functions for converting generic pub / sub calls into specific pub / sub calls compatible with the corresponding pub / sub service.

11. The DPU of claim 1, wherein the at least one processing core is configured to perform security functions to filter or block pub / sub calls based on predefined criteria without notifying the host device.

12. A system comprising: The host device is used to generate generic publish-subscribe Pub / Sub calls; as well as Data processing unit (DPU), coupled to the host device, the DPU comprising: A host interface is used to receive the general pub / sub calls from the host device; At least one processing core is configured to perform: an orchestration function to select a specific pub / sub service based on the generic pub / sub call; and a transformation layer to convert the generic pub / sub call into a specific pub / sub call compatible with the selected specific pub / sub service; and A forwarding interface is used to provide the transformed specific pub / sub call to the selected specific pub / sub service.

13. The system of claim 12, wherein the particular pub / sub service includes at least one of the following: a proxy-based pub / sub service or a proxyless pub / sub service.

14. The system of claim 12, wherein the general pub / sub call includes a publish message or a subscribe request.

15. The system of claim 12, wherein the orchestration function is used to maintain a mapping between topics and different pub / sub services.

16. The system of claim 15, wherein the orchestration function is used to select the specific pub / sub service based on the topic associated with the general pub / sub call.

17. The system according to claim 12, wherein: The host device is used to execute the paravirtualized pub / sub driver frontend; as well as The at least one processing core of the DPU is used to execute a paravirtualized pub / sub backend to interface with the paravirtualized pub / sub driver frontend running on the host device.

18. The system of claim 17, wherein the quasi-virtualized pub / sub backend includes multiple backend conversion functions of the conversion layer, each backend conversion function corresponding to a different pub / sub service.

19. The system of claim 12, wherein the general pub / sub call is included in a Remote Direct Memory Operation (RDMO) pub / sub command.

20. The system according to claim 19, wherein: The host device is used for: Generate the RDMO pub / sub command; Write the RDMO pub / sub command to the work queue stored in the host memory; and Send an RDMO notification to the DPU, the RDMO notification informing the DPU that the RDMO pub / sub command is in the work queue; and The orchestration function is used for: Receive the RDMO notification from the host device; In response to receiving the RDMO notification, the RDMO pub / sub command is read from the work queue; as well as The generic pub / sub call is derived from the read RDMO pub / sub command.

21. The system of claim 20, wherein the conversion layer includes a plurality of conversion functions for converting generic pub / sub calls into specific pub / sub calls compatible with the corresponding pub / sub service.

22. The system of claim 12, wherein the at least one processing core is configured to perform security functions to filter or block pub / sub calls based on predefined criteria without notifying the host device.

23. A method comprising: Receive generic publish-subscribe Pub / Sub calls from the host device; Select a specific pub / sub service based on the general pub / sub call; Convert the generic pub / sub call into a pub / sub call compatible with the selected specific pub / sub service; and The transformed pub / sub call is provided to the selected pub / sub service.

Images