Multi-tenant perception data processing unit

Abstract

Embodiments herein describe creating tag binds that can be used to assign tags to data corresponding to different tenants using a data processing unit (DPU), such as a SmartNIC, an artificial intelligence unit, a network storage unit, a database acceleration unit, etc. In one embodiment, the DPUs include tag gateways at an interface between a host and a network element (e.g., a switch) that identify and tag the data corresponding to the tenants. The tags are then identified by a data processing engine (DPE) in the DPU, such as an A1 engine, a cryptographic engine, a cryptographic engine, a direct memory access (DMA) engine, etc. The DPEs may be configured to execute tag policies that provide security isolation and performance isolation between the tenants.

Description

Technical Field

[0001] Examples of the present disclosure generally relate to a data processing unit (DPU) that uses the DPU to assign different tags to different tenants. The DPU may include multiple data processing engines (DPEs) that can implement different policies based on the tags to, for example, ensure tenant isolation (prevent snoopy neighbors) and meet performance requirements (prevent noisy neighbors). Background Art

[0002] Current acceleration devices such as smart network interface cards / controllers (SmartNICs) include different components such as I / O gateways, processor subsystems, networks on chips (NoCs), storage and data accelerators, data processing engines, and programmable logic (PL). In the prior art, these different components in an acceleration device are treated as separate monolithic components that simply pass work or transform data before forwarding to the next component. In the best case, these components are connected to each other through a common bus protocol such as the Advanced eXtensible Interface (AXI) or have a protocol bridge function that converts the protocol of one component (such as PCIe) to the protocol of another component (such as AXI).

[0003] When data is transferred from one component to the next, the properties or attributes of the data that are unique to one component or to a tenant in the service of a tenant's function are not propagated to the next component, making the two components opaque to each other even though the two components may be performing specific functions in the service of the same tenant. In other words, different components in the same accelerator device act independently of each other, even though they may perform interrelated operations. Some prior art techniques involve software intervention (e.g., a hypervisor or component firmware) to regain attributes that are unique to a tenant across various components (although a bridge may create an opaque boundary), so that whenever a component receives work or data from another component, the receiving component can regain the tenant's attributes through the intervening software. However, such software intervention generates overhead, particularly when cross-component services are implemented for multiple tenant functions. In addition, some tenants do not trust hypervisors or other software entities that intervene on their behalf (as in the case of bare metal deployments). Summary of the invention

[0004] One embodiment describes a multi-tenant-aware DPU, which includes: a first tag gateway, which is configured to be coupled to a host; a second tag gateway, which is configured to be coupled to a network, wherein the first tag gateway and the second tag gateway are configured to assign different tags to data received from different tenants; and multiple DPEs, which are configured to implement different tag policies based on these different tags when processing the received data.

[0005] Another embodiment described herein is a multi-tenant-aware DPU, in which a first tag gateway is coupled to a local interface of the DPU, and a second tag gateway is coupled to a remote interface of the DPU, wherein the first tag gateway and the second tag gateway are configured to assign different tags to data received from different tenants at the DPU, and multiple data processing engines (DPEs) are configured to implement different tag policies based on these different tags when processing the received data, so as to (i) isolate data received from different tenants and (ii) ensure that performance standards of these tenants are met.

[0006] Another embodiment described herein is a method comprising: receiving data from multiple tenants at a first tag gateway of a data processing unit (DPU); assigning different tags to data received from different tenants among the multiple tenants; and implementing different tag strategies when the tagged data from the multiple tenants is processed by a data processing engine (DPE) in the DPU. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to be able to understand in detail the manner in which the above features are described, a more specific description briefly summarized above may be obtained by reference to example implementations, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate only typical example implementations and therefore should not be considered to limit the scope thereof.

[0008] Figure 1 A system including a multi-tenant aware DPU according to one embodiment is shown.

[0009] Figure 2 A DPU implemented as a system on a chip is shown according to one embodiment.

[0010] Figure 3 is a flow chart for establishing end-to-end binding in a DPU according to an implementation scheme.

[0011] Figure 4 is a flow diagram for assigning tags to tenants and processing data at a DPE in a DPU using these tags, according to one embodiment.

[0012] Figure 5 and Figure 6 The use of tags to share resources between tenants according to several embodiments is shown.

[0013] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements of one example may be beneficially incorporated in other examples. DETAILED DESCRIPTION

[0014] Various features are described below with reference to the accompanying drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are represented by similar reference numerals in all drawings. It should be noted that the drawings are intended only to facilitate the description of the features. They are not intended to be an exhaustive description of the features nor to limit the scope of the claims. In addition, the illustrated examples do not necessarily have all the aspects or advantages shown. The aspects or advantages described in conjunction with a particular example are not necessarily limited to that example, and may be practiced in any other example even if not so illustrated or so explicitly described.

[0015] The embodiments herein describe creating tag bindings that can be used to assign tags to data corresponding to different tenants using data processing units (DPUs) such as SmartNICs, artificial intelligence units, network storage units, and database acceleration units. In one embodiment, the DPUs include tag gateways at the interface between the host and the network element (e.g., a switch), which identify and mark the data corresponding to the tenants. The tags are then identified by a data processing engine (DPE) (such as an AI engine, a cryptographic engine, an encryption engine, a direct memory access (DMA) engine, etc.) in the DPU. The DPEs can be configured to execute tag policies that provide security isolation and performance isolation between the tenants. For example, a tenant cannot access another tenant's data (e.g., to prevent snooping neighbors), or cannot obtain resources in the DPE that exceed its share (e.g., to prevent noisy neighbors). In this way, tag bindings can create end-to-end bindings through the DPU, where different DPEs in the DPU implement coordinated tag policies for specific tenants.

[0016] Figure 1 A system 100 including a multi-tenant aware DPU 110 according to one embodiment is shown. Specifically, the system 100 shows connecting the DPU 110 to a host 105 and a network 135. For example, the host 105 may include one or more processors (e.g., processor complexes) and memory that communicate with the DPU 110 using any number of PCIe connections 140.

[0017] The network 135 may include any number of network elements (e.g., one or more switches) coupled to the DPU 110 via an Ethernet connection 150. In one embodiment, the DPU 110 may be a SmartNIC, where the host 105 uses the DPE 120 in the DPU 110 to perform data processing tasks that would otherwise be performed by a processor on the host 105. The DPU 110 may be an AI accelerator unit that performs AI or machine learning tasks, a cryptographic unit that encrypts and decrypts data transmitted between the host 105 and the network 135, a network storage unit, a database acceleration unit for a cloud computing environment, and the like.

[0018] In one embodiment, the connection between DPU 110 and host 105 is a local interface, while the connection between DPU 110 and network 135 is a remote interface. These different interfaces can use different communication protocols. For example, the local interface between host 105 and DPU 110 can use PCIe, fast computing link (CXL) or cache coherent interconnect for accelerators (CCIX). The interface between DPU 110 and network 135 can use Infiniband or Ethernet.

[0019] The DPU 110 includes tag gateways 115 that tag data created by different tenants sharing the DPU 110. For example, multiple hosts 105 may be attached to the DPU 110 at different physical ports, where each host 105 is a different tenant. In another embodiment, a particular host 105 may have multiple VMs, each of which is considered a different tenant (e.g., executing different applications or associated with different customers in a cloud computing environment or data center). Thus, a tenant can be a physical computing system (e.g., a host 105), a virtual machine or container, a specific application, or a customer in a data center environment. In this way, a tenant can correspond to a physical component (e.g., a different port) or can be a logical construct (e.g., different customers using the same virtual machine or the same host 105).

[0020] The tag gateway 115A receives data from the host 105 and uses the attributes in the data to tag the data. In other words, the tag gateway 115A can use the identification attributes in the received data to determine that the data is from a specific tenant, and then assign a tag to the data corresponding to the identified tenant. For example, the gateway 115 can use the ID in the data to identify the tenant and provide a tag. In another embodiment, the gateway 115 can evaluate the data source (e.g., the host or VM sending the data, the application ID, the port receiving the data, etc.) to identify the tenant and provide a tag. In yet another embodiment, the gateway 115 can evaluate the destination or address range of the data to identify the tenant and tag the data.

[0021] In this embodiment, the DPU 110 includes a trusted entity 130, which may be the only entity in the DPU 110 that is allowed to configure the tag gateway 115A. The DPU 110 may include a firewall that ensures that only the trusted entity 130 can configure the tag gateway 115A to create tag bindings that link attributes in the data (e.g., ID, source information, destination information, etc.) to specific tags. Therefore, malicious external actors cannot access the tag gateway 115 to change or spoof the tag bindings. That is, the tags are not spoofable and cannot be changed.

[0022] In one embodiment, DPU 110 includes a complete hardware firewall so that tags assigned by tag gateway 115 are trusted. That is, once a tag is set by tag gateway 115, no other hardware, firmware, or software entity in DPU 110 can change the tag. However, in another embodiment, DPU 110 can support both trusted tags and untrusted tags. Each downstream hardware component in DPU 110 (e.g., DPE 120) can distinguish between trusted tags and untrusted tags.

[0023] In one embodiment, untrusted tags are assigned to tenants who accept a lower level of service (e.g., at a lower cost or no cost) and also accept being impacted by noisy or snoopy neighbors. For example, a cloud service provider may provide services to educational institutions at very low or no cost. These educational institutions receive computing, storage, and network resources for students to run their research applications. Educational institution tenants are assigned untrusted tags, which provide best effort (or residual computing power), but do not have the same level of data isolation as tenants assigned trusted tags. In another example, untrusted tags can also be used in the DPU to bypass the cryptographic engine / accelerator, thereby saving the cloud service provider capacity and cost in providing these services to educational institution tenants.

[0024] Once labeled, the data is provided to a pipeline 119 that includes multiple DPEs 120. DPEs 120 may be AI engines / accelerators, database engines / accelerators, cryptographic engines / accelerators, compression engines / accelerators, etc. DPEs 120 may be formed of hardened circuits, programmable logic (PL), or a combination of both.

[0025] In one embodiment, the DPEs 120 in the DPU 110 may all be the same type of engine or accelerator. For example, the DPU 110 may be designed to accelerate AI tasks associated with data transmitted between the host 105 and the network 135. In this case, all of the DPEs 120 may be AI engines. That is, the DPEs 120 may be homogeneous. Alternatively, the DPEs 120 may be heterogeneous, where the DPE 120A may be a DMA engine, the DPE 120B may be a cryptographic engine, and so on.

[0026] exist Figure 1 In the example, DPEs 120 are arranged in pipeline 119 so that data can be processed sequentially by multiple DPEs 120, but this is only an example. For example, data of one tenant can be passed through DPEs 120A and 120B, while data of another tenant can only be processed by DPE 120A and not by DPE 120B. In general, DPU 110 can have any number of DPEs 120, wherein when data of a particular tenant is transmitted through DPU 110, the tenant can use all, a subset, or none of the DPEs 120.

[0027] DPE 120 includes tag policies 125 that define how DPE 120 should handle differently tagged data. In other words, tag policies 125 dictate how DPE 120 should handle data for each of the tenants that may use DPU 110. For example, tag policy 125A may indicate that data tagged for Tenant A should be able to use up to 25% of the hardware resources in DPE 120A. Thus, if DPE 120A receives a burst of traffic from Tenant A, even if it has available, unused resources, tag policy 125A prevents DPE 120 from providing more than 25% of its resources to handle Tenant A's traffic. In this way, if DPE 120A receives a burst of traffic from Tenant B a short time later that should be given up to 75% of DPE 120A's resources, those resources are immediately available to Tenant B. In this example, tags and tag policies 125 prevent noisy neighbors (e.g., Tenant A) from using resources that should be used for Tenant B.

[0028] In addition, the tag policy 125 can provide tenant isolation, where tenants cannot access each other's data. For example, the DPU 110 may include a memory (not shown) that stores tenant data. If the DPE 120 attempts to access the data of Tenant A while processing the data of Tenant B, the tag policy can stop the attempt. This prevents a snooping neighbor situation, where one tenant may attempt to access the data of another tenant on a shared resource (DPU 110 or a hardware component in DPU 110). However, the tag policy 125 may indicate that some tenants can access the data of other tenants. For example, Tenant A and Tenant B may be virtual machines used by the same customer, while Tenant C may be a virtual machine of a different customer. The tag policy 125 may allow Tenant A and Tenant B to share data with each other, but not allow Tenant A and Tenant B to access the data of Tenant C, and vice versa.

[0029] Tag policies 125 for DPEs 120 may be the same or different. For example, tag policy 125A for DPE 120A may be different from tag policy 125B for DPE 120B. For example, tag policy 125 may give Tenant A a larger share of hardware resources in DPE 120A than DPE 120B.

[0030] Trusted entity 130 may also be tasked with configuring tag policy 125. In one embodiment, only trusted entity 130 may configure and change tag policy 125. This prevents malicious actors from changing the security and performance isolation established by tag policy 125. Figure 1 The trusted entity 130 is shown as being part of the DPU 110, but in other embodiments, the trusted entity 130 may be external to the DPU 110 but have a verified communication path to the DPU 110 in order to perform the functions described above.

[0031] The remote interface of the DPU 110 includes a tag gateway 115B that tags data received from the network 135. As with the local interface and tag gateway 115A, the gateway 115B can use physical attributes to identify tenants and tag data, such as which port the data was received on. Alternatively or additionally, the gateway 115B can tag the received data using attributes in the data, such as IP address, source / destination information, traffic flow identifiers, etc. Thus, the gateway 115B can perform logical tagging, where different traffic flows received on the same port can be identified as different tenants.

[0032] Typically, the marking performed by the gateway 115 and the tag policy 125 creates an end-to-end binding for each tenant as data flows from the host 105 to the network 135 and from the network 135 to the host 105. In addition, data traveling in the opposite direction may be associated with the same tenant and therefore assigned the same tag, but the interface of the DPU 110 uses a different protocol. For example, a specific traffic flow received from the network 135 at the DPU 110 and the data received from the host 105 at the DPU 110 may be part of the same tenant. Tag bindings can link different attributes to the same tag. For example, the tag gateway 115A may tag all data with a specific ID defined by the PCIe protocol with tag A, while the gateway 115B tags all data with a specific IP address with tag A. Therefore, although the data of the same tenant may be transmitted to the DPU 110 using different communication protocols, the tag binding in the tag gateway 115 may assign the same tag to the data using different attributes, thereby indicating that the data is for the same tenant. Thus, data of the same tenant may be assigned the same tag regardless of the direction in which the data flows through the DPU 110 .

[0033] Figure 2 The DPU is shown implemented as a system on chip (SoC) 200 according to one embodiment. SoC 200 (eg, an integrated circuit (IC)) may include a tag gateway 115, a DPE 120, and a trusted entity 130. In addition, Figure 2 A tag binding 205 within the tag gateway 115 is shown that may be generated by the trusted entity 130. As described above, the tag binding 205 may associate or link attributes in the data received by the SoC 200 from the host or network to a particular tag. For example, the tag gateway 115 may identify an ID, source, destination, address space, IP address, etc., and use the attribute to index the tag binding 205 to identify the tag of the data. In one embodiment, each tenant may be assigned a different tag, but different business flows may be assigned the same tag if the flows are part of the same tenant.

[0034] Tag binding 205A may include different properties than tag binding 205B because the interfaces used by gateways 115A and 115B may use different communication protocols, for example, gateway 115A uses PCIe, CXL, or CCIX, while gateway 115B uses Ethernet.

[0035] In this example, the DPE 120 includes a wrapper 215 (e.g., hardware circuitry) that implements the tag policy 125. For example, before the received data is processed at the DPE 120, the data first passes through the corresponding wrapper 215. The wrapper 215 can then implement policies for the tagged data, such as ensuring that the DPE 120 does not access data with a different tag, or ensuring that the DPE 120 does not assign more resources to process the data than it should. For example, if the wrapper 215 determines that the DPE 120 will expend more resources than allowed to process the received tagged data (e.g., the wrapper 215 receives a burst of data from a particular tenant), the wrapper can block a portion of the data (or throttle the data) so that the DPE 120 does not expend more resources than it should to process the data according to the tag policy 125.

[0036] However, using wrapper 215 to implement tag policies is merely an example. In other embodiments, DPE 120 may include a table storing tag policies 125. DPE 120 may index the table using a tag to identify a specific policy for that tag.

[0037] In yet another embodiment, the trusted entity 130 may statically assign the DPE 120 to a specific tenant. For example, two DPEs may be assigned to tenant A, and four DPEs may be assigned to tenant B. Tags may be used to route tenant A's data only to its two assigned DPEs, and tenant B's data only to its four DPEs. In another example, the SoC 200 may include multiple parallel pipelines of DPEs, where each pipeline may be statically assigned to a specific tenant, for example, tenant A's data is processed only by the first pipeline, tenant B's data is processed only by the second pipeline, and tenant C's data is processed only by the third pipeline and the fourth pipeline.

[0038] SoC 200 also includes a network on chip (NoC) 210 that facilitates communication between gateway 115 and DPE 120 and between DPEs 120. Although not shown, NoC 210 may include tag policies for providing data isolation and meeting performance requirements for tagged tenant data. However, NoC 210 is optional.

[0039] Although Figure 2 SoC implementations of a DPU that may include a single IC are shown, but in other embodiments, multiple ICs may be used to implement the DPU. For example, the DPU may include Figure 2 Anchor wafers for some of the hardware components shown and chiplets comprising the remaining hardware components.

[0040] Figure 3is a flow chart of a method 300 for establishing an end-to-end binding in a DPU according to an embodiment. At block 305, a trusted entity (e.g., Figure 1 The DPU may have a local interface that communicates with a host using a first communication protocol (e.g., PCIe or CXL) and a remote interface that communicates with a network device such as a switch using a second communication protocol (e.g., TCP / IP or UDP).

[0041] Due to different communication protocols, trusted entities may generate different tag bindings that depend on different properties. Therefore, tag bindings can be customized depending on the interface they will be deployed to.

[0042] At block 310, the trusted entity stores the tag binding in a tag gateway of the DPU.

[0043] At block 315, the trusted entity establishes a tag policy for the tag. The trusted entity may generate a tag policy for each hardware component in the DPU that will process tenant data. The tag policy may establish data isolation requirements for each tag (i.e., each tenant). The isolation requirements may implement security isolation between tenants and / or performance isolation between tenants.

[0044] At block 320, the trusted entity configures the DPE to implement the tag policy. This can be done in a variety of ways, such as using a wrapper, a table, or statically assigning certain DPEs to specific tag data. In addition, embodiments herein are not limited to providing tag policies to the DPE, but can also provide tag policies to the NOC or memory controller in the DPU.

[0045] Figure 4 is a flow chart of a method 400 for assigning tags to tenants and processing data at a DPE in a DPU using these tags, according to one embodiment. At block 405, the DPU receives data from a plurality of tenants. In one embodiment, the data comprises data packets, but this may depend on the communication protocol.

[0046] In one embodiment, the DPU receives packets on two different interfaces. One interface may be connected to one or more host computing systems (e.g., Figure 1 Another interface may be a local interface of a host 105 in the example. Another interface may be a remote interface of one or more network device portions connected to a network (e.g., network 135). The network may be a local area network (LAN), such as a data center network of a cloud service provider (CSP), or a wide area network (WAN), such as the Internet. In one embodiment, the interfaces use different communication protocols, such as PCIe or Ethernet.

[0047] At box 410, the DPU assigns a different tag to each of the tenants that transmit data to the DPU. For example, a tag gateway in the DPU may evaluate attributes in the received data to identify which tenant transmitted the data. As described above, a tenant can be a customer of a physical computing system, a virtual machine or container, a specific application, or a data center environment. In this way, a tenant can correspond to a physical component (e.g., different ports) or can be a logical construct (e.g., different customers using the same virtual machine or the same host). The data may include attributes such as an ID, source / destination address, port number, memory address, etc., which the tag gateway can use to identify a specific tag of the data that corresponds to the tenant that transmitted the data.

[0048] The tag gateway can then attach the tag to the data. The DPU can use a variety of different communication protocols to transfer data internally. Regardless of the protocol, the DPU can ensure that the tag remains with the data so that internal hardware components (such as DPE, DMA controller, memory controller, NoC, etc.) can recognize the tag and perform some action on the data based on the tag that accompanies the data.

[0049] At block 415, hardware components in the DPU (e.g., DPE) implement different tag policies when processing data for multiple tenants. For example, the DPE may include wrappers or policy tables that implement corresponding tag policies using the tags assigned at block 410. In one embodiment, tag policies may be defined to prevent snooping and noisy neighbors (i.e., tenants).

[0050] Box 415 may include two sub-boxes to prevent snooping and noisy neighbors. At box 420, the DPE isolates the tenants' data. That is, when processing tenant A's data, the tag policy may prevent the DPE from accessing another tenant's data. Or the tag policy may indicate that tenant A can access tenant B's data, but not tenant C's data.

[0051] At block 425, the DPE ensures that the tenant's performance standards are met. For example, the DPE may prevent Tenant A from using more than 33% of its hardware resources, even if there are currently unused hardware resources in the DPE. In this way, if the DPE receives data from a different tenant, the DPE has available hardware resources. Figure 5 and Figure 6 Different strategies for dealing with snoopy and noisy neighbors are discussed in .

[0052] Figure 5 and Figure 6 The use of tags to share resources between tenants according to several embodiments is shown. Figure 5A pipeline 500 of DPEs is shown that uses tag policies to ensure that the DPEs can meet the expected performance standards of tenants. Pipeline 500 includes DPEs 120A-C with corresponding hardware resources 505A-C. DPE 120A guarantees that tenant A can access up to 66% of its hardware resources 505A, while tenant B can access up to 34% of its hardware resources 505A. DPE 120B guarantees that tenant A can access up to 66% of its hardware resources 505B, while tenant B can access up to 34% of its hardware resources 505B. DPE 120C guarantees that tenant A can access up to 50% of its hardware resources 505C, while tenant B can access up to 50% of its hardware resources 505C. These hardware allocations can be set by tag policies. It should be noted that the tag policy of each of the DPEs need not be the same, as DPE 120C allocates its hardware resources 505C to Tenant A and Tenant B differently than DPEs 120A and 120B.

[0053] Ensuring that tenants do not exceed their maximum resource allocation in the DPE prevents the noisy neighbor problem, where one tenant may use most or all of the resources in the DPE, and then when another tenant's data arrives at the DPE, the DPE does not have any available hardware resources, forcing the tenant's data to wait, even though the tenant may have higher priority data. However, by using tags to identify tenant data, hardware resources 505 can be divided according to priority, ensuring that the DPE has available resources for different tenants.

[0054] Although not shown, snoopy neighbors may be addressed by DPE 120 having firewalls or control policies that prevent hardware resources processing Tenant A's data from accessing Tenant B's data and vice versa.

[0055] Figure 6 A plurality of DPE pipelines 600A-C with corresponding DPEs are shown. That is, pipeline 600A includes DPEs 120D-F, pipeline 600B includes DPEs 120G-I, and pipeline 600C includes DPEs 120J-L. In one embodiment, the DPEs in pipeline 600 are identical so that pipeline 600 can perform the same tasks (e.g., digital signal processing tasks or machine learning tasks). That is, each pipeline 600 can include the same three DPEs (which can be three DPEs of the same type or a combination of DPEs of different types).

[0056] In this embodiment, instead of dividing the hardware resources in the DPE, the trusted entity can assign each pipeline 600 to the corresponding tenant. That is, the data of tenant A is processed only by pipeline 600A, and the data of tenant B is processed only by pipelines 600B and 600C. Therefore, the data of tenant B has twice the processing bandwidth than the data of tenant A. In this way, each DPE 120 can be dedicated to or assigned to one tenant. Doing so solves the problem of noisy and snoopy neighbors because each pipeline 600 is limited to a single tenant. In addition, by assigning more pipelines to higher priority tenants (tenant B in this example), one tenant can be prioritized over another tenant.

[0057] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the described features and elements (whether or not involving different embodiments) is contemplated as implementing and practicing the contemplated embodiments. In addition, although the embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Therefore, the foregoing aspects, features, embodiments and advantages are merely illustrative and are not considered to be elements or limitations of the appended claims unless expressly stated in the claims.

[0058] As will be appreciated by those skilled in the art, the embodiments disclosed herein may be embodied as systems, methods, or computer program products. Thus, various aspects may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Additionally, various aspects may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0059] Any combination of one or more computer-readable media may be utilized. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example but not limited to, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or apparatus, or any suitable combination of the foregoing. More specific examples (not a complete list) of computer-readable storage media would include the following: an electrical connector having one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium is any tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device or apparatus.

[0060] A computer readable signal medium may include a propagated data signal having computer readable program code embodied therein (e.g., in baseband or as part of a carrier wave). Such a propagated signal may take any of a variety of forms, including but not limited to electromagnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0061] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0062] The computer program code for performing operations for various aspects of the present disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Java, Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as "C" programming language or similar programming languages). The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer or completely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0063] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of the methods, devices (systems) and computer program products of the embodiments presented in the present disclosure. It should be understood that each frame of the flowchart illustration and / or block diagram and the combination of frames in the flowchart illustration and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that instructions executed by a processor of a computer or other programmable data processing device create components for implementing the functions / actions specified in one or more frames of a flowchart and / or block diagram.

[0064] These computer program instructions may also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a specific manner, so that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0065] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operating steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented method, so that the instructions executed on the computer or other programmable apparatus provide a process for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0066] The flow chart and block diagram in the figure illustrate the possible concrete implementation architecture, functionality and operation of the system, method and computer program product according to various examples of the present invention.In this regard, each frame in the flow chart or block diagram may represent the module, segment or part of one or more executable instructions for realizing the specified logical function of the instruction.In some alternative implementations, the function pointed out in the frame may not occur in the order pointed out in the figure.For example, depending on the functionality involved, the two frames shown in succession can actually be performed substantially at the same time, or these frames can sometimes be performed in reverse order.It will also be noted that each frame in the block diagram and / or flow chart illustration and the combination of the frames in the block diagram and / or flow chart illustration can be realized by a system based on special hardware that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0067] The techniques disclosed above can be expressed in the following non-limiting examples.

[0068] Embodiment 1. A multi-tenant-aware data processing unit (DPU), the multi-tenant-aware DPU comprising: a first tag gateway, the first tag gateway being configured to be coupled to a host; a second tag gateway, the second tag gateway being configured to be coupled to a network, wherein the first tag gateway and the second tag gateway are configured to assign different tags to data received from different tenants; and a plurality of data processing engines (DPEs), the plurality of DPEs being configured to implement different tag strategies based on the different tags when processing the received data.

[0069] Embodiment 2. The DPU of embodiment 1, wherein the data is received at the first tag gateway using a first communication protocol that is different from a second communication protocol used by the data received at the second tag gateway.

[0070] Embodiment 3. A DPU according to embodiment 2, wherein the first tag gateway is configured to evaluate a first attribute associated with the first communication protocol when assigning the tag, and the second tag gateway is configured to evaluate a second attribute associated with the second communication protocol when assigning the tag, wherein a first value of the first attribute and a second value of the second attribute are associated with the same tag to indicate that the first value and the second value are associated with the same tenant.

[0071] Embodiment 4. The DPU according to embodiment 1, wherein the label provides end-to-end binding through the DPU, so that for a specific label, the multiple DPEs implement the same label policy.

[0072] Embodiment 5. The DPU of embodiment 1, wherein the tag is not spoofable and cannot be changed by the multiple DPEs, wherein the first portion of the tag is a tag that is trusted by the multiple DPEs and the second portion of the tag is a tag that is not trusted by the multiple DPEs.

[0073] Embodiment 6. According to the DPU described in Embodiment 1, the DPU also includes: a trusted entity, which is configured to (i) establish a label binding in the first label gateway and the second label gateway, and the label binding is used to assign a label to the received data, and (ii) configure different label policies in each DPE of the multiple DPEs.

[0074] Embodiment 7. The DPU of embodiment 1, wherein the plurality of DPEs include respective wrappers that implement the different tagging policies.

[0075] Embodiment 8. The DPU of embodiment 1, wherein the different tag policies indicate that in a first DPE of the plurality of DPEs, a first tenant is allocated a larger maximum share of hardware resources than a second tenant.

[0076] Embodiment 9. A DPU according to embodiment 1, wherein the different tag policies indicate that the first tenant is allocated a greater number of dedicated DPEs among the plurality of DPEs than the second tenant.

[0077] Embodiment 10. The DPU of embodiment 1, wherein the DPU is implemented as a smart network interface controller (SmartNIC).

[0078] Embodiment 11. A multi-tenant-aware data processing unit (DPU), comprising: a first tag gateway, the first tag gateway coupled to the local interface of the DPU; a second tag gateway, the second tag gateway coupled to the remote interface of the DPU, wherein the first tag gateway and the second tag gateway are configured to assign different tags to data received from different tenants at the DPU; and multiple data processing engines (DPEs), the multiple DPEs are configured to implement different tag policies based on the different tags when processing the received data, so as to (i) isolate the data received from different tenants, and (ii) ensure that the performance standards of the tenants are met.

[0079] Embodiment 12. The DPU of embodiment 11, wherein the data is received at the first tag gateway using a first communication protocol that is different from a second communication protocol used by the data received at the second tag gateway.

[0080] Embodiment 13. A DPU according to embodiment 12, wherein the first tag gateway is configured to evaluate a first attribute associated with the first communication protocol when assigning the tag, and the second tag gateway is configured to evaluate a second attribute associated with the second communication protocol when assigning the tag, wherein a first value of the first attribute and a second value of the second attribute are associated with the same tag to indicate that the first value and the second value are associated with the same tenant.

[0081] Embodiment 14. The DPU according to embodiment 11, wherein the tag provides end-to-end binding through the DPU, so that for a specific tag, the multiple DPEs implement the same tag policy.

[0082] Embodiment 15. A method, comprising: receiving data from multiple tenants at a first tag gateway of a data processing unit (DPU); assigning different tags to data received from different tenants among the multiple tenants; and implementing different tag strategies when the tagged data from the multiple tenants are processed by a data processing engine (DPE) in the DPU.

[0083] Embodiment 16. According to the method described in Embodiment 15, the method also includes: receiving data from the multiple tenants at a second tag gateway of the DPU; using the second tag gateway to assign different tags to the data received from different tenants among the multiple tenants, wherein the data is received at the first tag gateway using a first communication protocol, and the first communication protocol is different from a second communication protocol used for the data received at the second tag gateway.

[0084] Embodiment 17. A method according to embodiment 16, wherein the first tag gateway evaluates a first attribute associated with the first communication protocol when assigning the tag, and the second tag gateway evaluates a second attribute associated with the second communication protocol when assigning the tag, wherein the first value of the first attribute and the second value of the second attribute are associated with the same tag to indicate that the first value and the second value are associated with the same tenant.

[0085] Embodiment 18. The method according to embodiment 15, wherein the tag provides end-to-end binding through the DPU, so that for a specific tag, the DPE implements the same tag policy.

[0086] Embodiment 19. The method of embodiment 15, wherein the tag is non-spoofable and cannot be altered by the DPE.

[0087] Embodiment 20. According to the method described in Embodiment 15, the method further includes: using a trusted entity to establish a label binding in the first label gateway, wherein the label binding is used to assign a label to the received data; and using the trusted entity to configure the different label policies in each DPE of the DPE.

[0088] While the foregoing is directed to particular examples, other and further examples may be devised without departing from the basic scope of the invention, and the scope of the invention is determined by the following claims.

Claims

1. A multi-tenant aware data processing unit (DPU), the multi-tenant aware DPU comprising: a first tag gateway configured to be coupled to a host; a second tag gateway configured to be coupled to the network, wherein the first tag gateway and the second tag gateway are configured to assign different tags to data received from different tenants; and A plurality of data processing engines (DPEs) are configured to implement different tag policies based on the different tags when processing the received data.

2. The DPU of claim 1, wherein the tag is non-spoofable and cannot be changed by the plurality of DPEs, wherein a first portion of the tag is a tag that is trusted by the plurality of DPEs and a second portion of the tag is a tag that is untrusted by the plurality of DPEs.

3. The DPU according to claim 1, further comprising: A trusted entity is configured to (i) establish a tag binding in the first tag gateway and the second tag gateway, wherein the tag binding is used to assign a tag to the received data, and (ii) configure a different tag policy in each DPE of the plurality of DPEs.

4. The DPU of claim 1, wherein the plurality of DPEs include respective wrappers that implement the different tag policies.

5. The DPU of claim 1, wherein the different tag policies indicate that in a first DPE of the plurality of DPEs, a first tenant is allocated a larger maximum share of hardware resources than a second tenant.

6. The DPU of claim 1, wherein the different tag policies indicate that a first tenant is allocated a greater number of dedicated DPEs among the plurality of DPEs than a second tenant.

7. The DPU of claim 1, wherein the DPU is implemented as a smart network interface controller (SmartNIC).

8. A multi-tenant aware data processing unit (DPU), the multi-tenant aware DPU comprising: a first tag gateway, the first tag gateway coupled to a local interface of the DPU; a second tag gateway coupled to a remote interface of the DPU, wherein the first tag gateway and the second tag gateway are configured to assign different tags at the DPU to data received from different tenants; and A plurality of data processing engines (DPEs) are configured to implement different tag policies based on the different tags when processing the received data so as to (i) isolate data received from different tenants and (ii) ensure that performance standards of the tenants are met.

9. The DPU of claim 1 or claim 8, wherein the data is received at the first tag gateway using a first communication protocol, the first communication protocol being different from a second communication protocol used by data received at the second tag gateway.

10. The DPU of claim 12, wherein the first tag gateway is configured to evaluate a first attribute associated with the first communication protocol when assigning the tag, and the second tag gateway is configured to evaluate a second attribute associated with the second communication protocol when assigning the tag, wherein a first value of the first attribute and a second value of the second attribute are associated with the same tag to indicate that the first value and the second value are associated with the same tenant.

11. The DPU according to claim 1 or claim 8, wherein the label provides end-to-end binding through the DPU, so that for a specific label, the multiple DPEs implement the same label policy.

12. A method comprising: receiving data from a plurality of tenants at a first tag gateway of a data processing unit (DPU); assigning different tags to the data received from different tenants among the plurality of tenants; as well as When the tagged data from the multiple tenants is processed by a data processing engine (DPE) in the DPU, different tagging policies are implemented.

13. The method according to claim 12, further comprising: receiving, at a second tag gateway of the DPU, data from the plurality of tenants; as well as The second tag gateway is used to assign different tags to the data received from different tenants of the plurality of tenants, wherein the data is received at the first tag gateway using a first communication protocol, the first communication protocol being different from a second communication protocol used by the data received at the second tag gateway.

14. The method of claim 12, wherein the tag provides end-to-end binding through the DPU such that for a particular tag, the DPEs implement the same tag policy, and wherein the tag is not spoofable and cannot be changed by the DPE.

15. The method according to claim 15, further comprising: establishing, using a trusted entity, a tag binding in the first tag gateway, the tag binding being used to assign a tag to the received data; as well as The different tag policies are configured in each of the DPEs using the trusted entity.

Images