METHOD FOR EXECUTING A REQUEST TO EXCHANGE DATA BETWEEN FIRST AND SECOND DISJOINT PHYSICAL ADDRESSING SPACES OF CHIP OR CARD CIRCUIT

This method for executing a request to exchange data, between first and second disjoint physical addressing spaces controlled by first and second distinct circuits for first and second respective software processes, comprises the creation of a communication channel between these two circuits. It further comprises sending, by the first process, of said request to exchange data, this request designates a virtual address in a virtual addressing space of the second process, and execution of the request to exchange data between the disjoint physical addressing spaces of the two processes, without invoking a processor executing the second process. During creation of the channel, a translation of the virtual addressing space of the second process into its physical addressing space is created and associated with this channel in the second circuit. During execution of the request, data for identification of the channel is added to the virtual address designated in the request.

This invention relates to a method for executing a request to exchange data between first and second disjoint physical addressing spaces respectively controlled by first and second separate chip or card circuits.

Generally, the two circuits can be mounted on various cards or chips, on the same card or on the same chip, even in the same box thanks to using integration technologies of the SiP (“Silicon in Package”) or 3D types.

Generally also, the two circuits are interconnected by fast communication links that allow each one to access the physical addressing space controlled by the other. These links can take the form of an interconnection matrix of a network on a chip, of a transmission bus, of a high-speed Fiber Channel connection with a point-to-point, ring or switched topology, etc.

The technological context wherein such a request to exchange data is led to be executed primarily relates to multiprocessor architectures with interconnected calculation nodes and techniques for grouping computers into server clusters making it possible to meet the increasing needs for computing power. It is as such possible to design computers of the HPC (“High Performance Computing”) type which can integrate up to ten thousand basic microprocessors with very high clock frequencies and low consumption, interconnected together by very high speed links. In these architectures, qualified as “scale-out”, the memory is distributed between the processors into a plurality of high-capacity local memories and data can be constantly exchanged at high speed from one local memory to another according to processing distributed over several processors that are working in parallel. In these architectures also, circuits provided with processors are generally further provided with hardware support for the virtualization of their operating systems with mechanisms for accelerating this virtualization, for direct memory access control with multiple channels using the RDMA (“Remote Direct Memory Access”) programming model and for the translation of virtual addresses into physical addresses.

The aim can be to reach a maximum of Giga Flops (“Floating-point Operations Per Second”) by invoking a maximum of computers and interconnections at the same time.

The aim can also be to respond to a requirement of energy proportionality required by the computing loads produced by the applications of the family of cloud computing processing of which the variability is a major characteristic. As these applications are widely distributed, memory-hungry and hungry in terms of input/output, but in the end rather little in computing properly speaking, “scale-out” architectures, more efficient from an energy standpoint, are better suited to these new families of applications.

In this context, the invention applies more particularly to a method for executing a request to exchange data comprising the following steps:creation of a communication channel between:a first access port of the first circuit, obtained by a first software process that executes in the first circuit that comprises at least one processor for executing this first software process in the first physical addressing space, anda second access port of the second circuit, obtained by a second software process that executes in the second circuit that comprises at least one processor for executing this second software process in the second physical addressing space,sending, by the first software process, of said request to exchange data, wherein this request designates a virtual address in a virtual addressing space of the second software process, andexecuting, by managers of the first and second access ports, of the request to exchange data between the disjoint physical addressing spaces of the two software processes, without invoking the processor executing the second software process.

In order to avoid invoking the processors of the circuits, and in particular that of the second circuit, such a method is generally implemented using expensive network adapters and which are not very efficient from an energy standpoint, for example according to the RoCE (“RDMA over Converged Ethemet”) protocol with 10 Gigabit Ethernet technology used to implement the IEEE 802.3 standard at speeds between 1,000 and 10.000 Mbits/s, according to the Infiniband technology, or according to other technologies and protocols. A concrete example of implementation via the MPI (“Message Passing Interface”) standard in RDMA programming on Infiniband is for example described in the article by Liu et al, entitled “High performance RDMA-based MPI implementation over infiniband”, published in the International Journal of Parallel Programming, Special issue I: The 17th Annual International Conference on Supercomputing (ICS'03), volume 32, no. 3, pages 167-198, June 2004. Another example implementing PCI Express adapters and the PCI-SIG protocol is disclosed in European patent application EP 2 680 155 A1. It should be noted that, regardless of the adapters required, they are further able to add latency in the exchanges of data.

It can as such be desired to provide a method for executing a request to exchange data that makes it possible to overcome at least part of aforementioned problems and constraints.

A method is therefore proposed for executing a request to exchange data between first and second disjoint physical addressing spaces respectively controlled by first and second separate chip or card circuits, comprising the following steps:creation of a communication channel between:a first access port of the first circuit, obtained by a first software process that executes in the first circuit that comprises at least one processor for executing this first software process in the first physical addressing space, anda second access port of the second circuit, obtained by a second software process that executes in the second circuit that comprises at least one processor for executing this second software process in the second physical addressing space,sending, by the first software process, of said request to exchange data, wherein this request designates a virtual address in a virtual addressing space of the second software process, andexecuting, by managers of the first and second access ports, of the request to exchange data between the disjoint physical addressing spaces of the two software processes, without invoking the processor executing the second software process.
according to which:during the creation of the communication channel, a translation of the virtual addressing space of the second software process into its physical addressing space is created and associated to this communication channel in the second circuit, andduring the execution of the request, data for identification of the communication channel is added to the virtual address designated in the request.

As such, through an inexpensive cunning and without any substantial increase in energy costs, i.e. the adding a few bits to the virtual address designated in the request in order to insert therein data for the identification of the communication channel, it is possible to execute on the side of the second circuit a fast and easy translation of this virtual address into a physical address of the physical addressing space controlled by the second circuit, without invoking its processor and without any need in terms of network adaptation.

Optionally, the translation of the virtual addressing space of the second software process into its physical addressing space is used by a memory management unit of the second circuit in order to determine which physical address of the second physical addressing space corresponds to the virtual address designated in the request using data for the identification of the communication channel added to this virtual address.

Optionally also, the data for the identification of the communication channel added to the virtual address designated in the request comprises an identifier of the second circuit, of an operating system whereon the second software process is executed and of the second access port obtained by the second software process, and an identifier of an exchange buffer memory defined on the side of the second circuit.

Optionally also, the data for the identification of the communication channel is added to the virtual address designated in the request by the manager of the first access port of the first circuit.

Optionally also, the adding of data for the identification of the communication channel to the virtual address designated in the request is carried out through encapsulation of this virtual address in a transport address, with this transport address being sent then processed by the manager of the second access port as a virtual address to be translated.

Optionally also, the execution of the request is managed by direct communication established between the processor of the first circuit and a local memory of the second circuit.

In this case, optionally:the translation of the virtual addressing space of the first software process into its physical addressing space is used by a memory management unit of the processor of the first circuit, andthis memory management unit further makes use of the translation of the virtual addressing space of the second software process into a temporary physical addressing space used to index a look-up table wherein the data for the identification of the communication channel is stored.

Optionally also, the execution of the request is managed by an indirect communication established between the processor of the first circuit and a local memory of the second circuit with the invoking of a direct memory access controller for read and write access, in local memory or remotely, independent of the processor of the first circuit.

In this case, optionally:the translation of the virtual addressing space of the first software process into its physical addressing space is used by a memory management unit associated specifically to the direct memory access controller, andthis memory management unit further makes use of the translation of the virtual addressing space of the second software process into a temporary physical addressing space used to index a look-up table wherein the data for the identification of the communication channel is stored.

Optionally also, the request to exchange data sent by the first software process concerns:a reading of the data stored in the first physical addressing space wherein the first software process is executed and a writing of this data in the second physical addressing space wherein the second software process is executed, ora reading of the data stored in the second physical addressing space wherein the second software process is executed and a writing of this data in the first physical addressing space wherein the first software process is executed.

Optionally also, at least one of the first and second software processes is executed on a virtual machine which is itself executed by a hypervisor of the corresponding processor, with each translation of a virtual address into a corresponding local physical address comprising a translation of the virtual address into an intermediate physical address as viewed by the virtual machine and a translation of the intermediate physical address into a physical address as seen by the hypervisor.

The system10, on a card or chip, diagrammatically shown inFIG. 1, comprises a plurality of circuits of which only two are shown.

A first circuit12comprises a main processor14, of the mono- or multi-processor, mono- or multi-core type. It is moreover associated with a local memory16and comprises, for read or write access therein, a memory controller18. It further comprises a coprocessor20for direct memory access, more precisely a DMA (“Direct Memory Access”) controller. Direct memory access is a well-known computing method according to which data coming from or intended to be sent to a peripheral device, for example another circuit of the system10, is transferred directly by the DMA controller20to or from the local memory16, without intervention of the main processor14except for launching and concluding the transfer. The first circuit12further has an interface22for connecting to the rest of the system10. The main processor14, the memory controller18, the DMA controller20and the interface22are interconnected in the first circuit12using an internal interconnection network24.

The main processor14is intended to execute instructions of software processes in physical addressing spaces which are reserved for them in local memory16. It can do this by the intermediary of an operating system that is proper to it or by the intermediary of one or more guest operating systems, qualified as “virtual machines”, which are themselves executed by a hypervisor or VMM (“Virtual Machine Monitor”). In any case, the memory addresses identified in the instructions of the software processes are virtual and have to be translated into physical addresses in the corresponding physical addressing spaces for good execution of these instructions. That is why the main processor14comprises a memory management unit26, called MMU (“Memory Management Unit”), of which the function is to carry out these translations of virtual addresses into physical addresses for each software process. When a software process is executed directly on the operating system of the main processor14, a single level of translation of a virtual address into a physical address is carried out by the MMU26. On the other hand, when a software process is executed on a virtual machine of the main processor14, two levels of translation of a virtual address into an intermediate physical address (the one viewed by the virtual machine), then of the intermediate physical address into a physical address (that as viewed by the hypervisor), are carried out by the MMU26.

With regards to the DMA controller20of which the read and write access to the local memory16are independent of the main processor14, it also manages virtual addresses of process Instructions, in such a way that it also needs a memory management unit28independent of the MMU26. This memory management unit28specific to the DMA controller20is generally called IOMMU (“Input/Output Memory Management Unit”) because it concerns input/output of the first circuit12. It has one or two levels of translation.

Moreover, as shall be seen in what follows for the implementing of a data exchange according to the invention, the first circuit12comprises an additional memory management unit30, independent of the MMU26and of the IOMMU28, for translating into physical addresses of the local memory16, virtual addresses included in requests to exchange data received by the first circuit12via the interface22. This additional memory management unit30is also generally called IOMMU because it also concerns input/output of the first circuit12. It also has one or two levels of translation.

Finally, as shall be seen also in what follows for the implementing of a data exchange according to the invention, the first circuit12comprises means for putting virtual addresses into correspondence with identification data of the communication channels established between software processes of the first circuit12and software processes of other circuits. These means take for example the form of a correspondence table32, generally called an LUT (“Look-Up Table”), used to add communication channel identification data in requests to exchange data sent by the first circuit12via the interface22.

A second circuit34shown inFIG. 1is identical to the first circuit12. It comprises a main processor36, is associated with a local memory38and comprises, for read or write access therein, a memory controller40. It further has a DMA controller42and an interface44for connecting to the rest of the system10. The main processor36, the memory controller40, the DMA controller42and the interface44are interconnected in the second circuit34using an internal interconnection network46.

The main processor36comprises an MMU48of which the function is to carry out translations of virtual addresses into physical addresses for each software process that it executes. As with the first circuit12, when a software process is executed directly on the operating system of the main processor36, a single level of translation of a virtual address into a physical address is carried out by the MMU48. On the other hand, when a software process is executed on a virtual machine of the main processor36, two levels of translation of a virtual address into an intermediate physical address (the one viewed by the virtual machine), then of the intermediate physical address into a physical address (that as viewed by the hypervisor), are carried out by the MMU48.

With regards to the DMA controller42of which the read and write access to the local memory38are independent of the main processor36, it also manages virtual addresses of process instructions, so that it is associated with an IOMMU50with one or two levels of translation.

Moreover, by symmetry with the first circuit12, the second circuit34comprises an additional IOMMU52with one or two levels of translation, independent of the MMU48and of the IOMMU50, for translating into physical addresses of the local memory38, virtual addresses included in requests to exchange data received by the second circuit34via the interface44.

Finally, also by symmetry with the first circuit12, the second circuit34comprises means for putting virtual addresses into correspondence with identification data of the communication channels established between software processes of the second circuit34and software processes of other circuits. These means take for example the form of a LUT54, used to add communication channel identification data in requests to exchange data sent by the second circuit34via the interface44.

The first and second circuits12and34are connected to each other using an interconnection56that can take the form of an interconnection matrix of a network on a chip, of a transmission bus, of a high-speed Fiber Channel connection with a point-to-point, ring or switched topology, etc.

A method for executing a request to exchange data between disjoint physical addressing spaces respectively controlled by the first and second circuits12and34shall now be described in detail in reference toFIGS. 2A, 2B and 3A, 38according to various possible embodiments. In these figures and by way of a non-limiting example, the request is sent by a first software process that executes in the first circuit12, with a first physical addressing space being allocated to this first software process in the local memory16by the main processor14. It relates to an exchange of data with a second physical addressing space, disjoint from the first, allocated in the local memory38by the main processor36to a second software process executing in the second circuit34.

In accordance with a first embodiment of the invention,FIG. 2Ashows the implementation of such a method in the following context:a direct communication, i.e. without invoking the controller DMA20and its IOMMU28, can be established between the main processor14of the first circuit12and the local memory38of the second circuit34,the virtual addresses are coded over 64 bits and the physical addresses over 48 bits,the first software process that is sending the request to exchange data is executed directly on the operating system of the main processor14, andThe required data exchange is a remote write, i.e. a reading of the data stored in the first physical addressing space of the memory16wherein the first software process is executed and a writing of this data in the second physical addressing space of the memory38wherein the second software process is executed.

In this embodiment, the presence of the controller DMA20and of its IOMMU28is not necessary. By symmetry, the presence of the controller DMA42and of its IOMMU50also is not necessary.

During a first step of negotiation100of a phase of creating a communication channel, a communication channel is negotiated between a first access port of the first circuit12, obtained by the first software process that executes in the first circuit12, and a second access port of the second circuit34, obtained by the second software process executing in the second circuit34. In accordance with this transaction established between the two software processes of which the physical addressing spaces are concerned by the exchange, an exchange memory buffer is allocated by the operating system of the main processor14, with this buffer memory defining a first virtual addressing space to be used for the first software process and a second virtual addressing space to be used for the second software process in the first circuit12. Likewise via reciprocity, an exchange buffer memory is also allocated by the operating system of the main processor36on the side of the second circuit34. Using by way of a non-limiting example a semantic of the Infiniband type, the communication channel can be entirely identified by the following data quadruplet:LIDSRC: a parameter, for example coded over 16 bits, that identifies the first circuit12, the operating system whereon the first software process is executed in the first circuit12and the first access port of the first circuit12,KEYSRC: a parameter, for example coded over 16 bits, which securely identifies the exchange buffer memory defined on the side of the first circuit12,LIDDEST: a parameter, for example coded over 16 bits, that identifies the second circuit34, the operating system whereon the second software process is executed in the second circuit34and the second access port of the second circuit34,KEYDEST: a parameter, for example coded over 16 bits, which securely identifies the exchange buffer memory defined on the side of the second circuit34.

This quadruplet (LIDSRC, KEYSRC, LIDDEST, KEYDEST) uniquely defines the transaction established between the two software processes concerned by the data exchange.

More precisely, the pair (LIDSRC, KEYSRC) defines the memory context to be used possibly on the side of the first circuit12in order to carry out the translations between virtual addresses and physical addresses and the pair (LIDDEST, KEYDEST) defines the memory context to be used on the side of the second circuit34in order to carry out the translations between virtual addresses and physical addresses. The four parameters are filled in during the first step100and stored in memory by the two circuits12and34. Note that the protocol implemented for the negotiation of this quadruplet of parameters is independent of this invention and can be chosen freely from protocols that are well known to those skilled in the art.

During a following step of configuring102the creation phase of the communication channel, the MMU26of the main processor14of the first circuit12is configured to carry out a translation of the virtual addressing space of the first software process into its physical addressing space. This can be done in association with the communication channel negotiated, i.e. in association with the memory context (LIDSRC, KEYSRC), but in direct communication between the main processor14of the first circuit12and the local memory38of the second circuit34this can also be done in another way, in a way known per se, without needing this memory context. Likewise, the IOMMU52of the second circuit34is configured to carry out a translation of the virtual addressing space of the second software process into its physical addressing space in association with the communication channel negotiated, i.e. In association with the memory context (LIDDEST, KEYDEST). Furthermore, the MMU26of the main processor14of the first circuit12is configured to carry out a translation of the virtual addressing space of the second software process into a temporary physical addressing space, representing the physical addressing space of the second software process as viewed from the first circuit12. Finally, the LUT32of the first circuit12is configured to associate this temporary physical addressing space to the memory context (LIDDEST, KEYDEST) that can be used by the second circuit34.

Then, during a step104, the first software process sends a remote write request, with this request designating a first virtual address VASRCof data to be read in the first virtual addressing space of the first software process and a second virtual address VADESTwherein to write the data read, with this second virtual address VADESTbeing included in the second virtual addressing space of the second software process.

These two virtual addresses VASRCand VADESTare coded over 64 bits.

During a following step106, the virtual address VASRCis translated by the MMU26into a 48-bit physical address PASRC. This physical address PASRCprecisely locates the data to be read in the local memory16, in the physical addressing space allocated to the first software process by the main processor14.

Then, during a read step108, the data to be read in the local memory16is read.

During a following step110, the virtual address VADESTis translated by the MMU26into a temporary physical address TPADEST. This temporary physical address TPADESTis coded over 48 bits and does not have any concrete signification. On the other hand, it comprises a translation IOVADESTof the second virtual address VADEST, coded over 32 bits and that can be used by the IOMMU52of the second circuit34, a parameter IKEYDESTcoded over 12 bits, with this parameter IKEYDESTbeing derived from the parameter KEYDESTin order to index the LUT32, a complement at 0 to the 47thbit and a most significant bit at 1. It as such takes for example the following form:

The most significant bit at 1 indicates for example that this temporary physical address indexes the LUT32.

During a following step112, a manager of the first access port of the first circuit12(i.e. the operating system of the main processor14) recovers, using the LUT32indexed by the temporary physical address TPADEST, in particular by its parameter IKEYDEST, the pair (LIDDEST, KEYDEST) identifying the memory context that can be used by the second circuit34. It makes use of this to add the parameters of this pair to the virtual address IOVADESTnow designated in the remote write request.

By way of a concrete example, the temporary physical address TPADESTis translated into a transport address TADESTcoded over 64 bits:

The remote write request is then transmitted by the manager of the first access port of the first circuit12to the interconnection56via the interface22during a transmission step114. This request comprises the transport address TADESTaccompanied by the parameter LIDDEST. It is conventionally routed through the interconnection56to the second circuit34. This routing can be facilitated thanks to specific information contained in the parameter LIDDEST.

Upon reception116of this request by a manager of the second access port of the second circuit34(i.e. the operating system or the hypervisor of the main processor36), the transport address TADESTaccompanied by the parameter LIDDESTis translated by the IOMMU52into a physical address PADESTover 48 bits thanks to the virtual address IOVADEST, included in the transport address TADEST, and to at least one portion of the data of the context memory (LIDDEST, KEYDEST) of which the parameter KEYDESTis included in the transport address TADESTand of which the parameter LIDDESTaccompanies this transport address. The manager of the second access port of the second circuit34therefore does not need to invoke the main processor36in order to carry out this translation.

Then, during a step of writing118, the data read in the local memory16is written in the local memory38, at the physical address designated by PADEST.

The path of the read and write access of the method ofFIG. 2Ais shown inFIG. 2B. Note that, even if the main processor14of the first circuit12is invoked for a remote write, this is not the case of the main processor36of the second circuit34. It is further noted that no particular network adapter is invoked.

Note that it is simple to adapt the method described hereinabove to a remote read. It is sufficient to send a read request in the step104, then to execute steps110to116instead of step106, then to replace step118with a step118′ of reading data at the physical address PADESTof the local memory38, then of transmitting this data read to the first circuit12, then to execute the step106, then finally to replace the step108with a step108′ of writing data to the physical address PASRCof the local memory16.

Note also that it is simple to adapt the method described hereinabove for a data exchange of which the request would be sent at the initiative of the second software process of the second circuit34.

As such, by symmetry, during the step of configuration102, the MMU48of the main processor36of the second circuit34can be configured to carry out a translation of the virtual addressing space of the second software process into its physical addressing space in association with the communication channel negotiated. i.e. in association with the memory context (LIDDEST, KEYDEST). Likewise, the IOMMU of the first circuit12can be configured to carry out a translation of the virtual addressing space of the first software process into its physical addressing space in association with the communication channel negotiated, i.e. in association with the memory context (LIDSRC, KEYSRC). Furthermore, the MMU48of the main processor36of the second circuit34can be configured to carry out a translation of the virtual addressing space of the second software process into a temporary physical addressing space, representing the physical addressing space of the first software process as viewed from the second circuit34. Finally, the LUT54of the second circuit34can be configured to associate this temporary physical addressing space to the memory context (LIDSRC, KEYSRC) that can be used by the first circuit12. It is then sufficient to adapt the steps104to118for a remote read or write sent from the second circuit34.

In accordance with a second embodiment of the invention,FIG. 3Ashows the implementation of a method for executing a request to exchange data in the following context:an indirect communication, i.e. with the invoking of the controller DMA20and of its IOMMU28, is established between the main processor14of the first circuit12and the local memory38of the second circuit34,the virtual addresses are coded over 64 bits and the physical addresses over 48 bits,the first software process that is sending the request to exchange data is executed directly on the operating system of the main processor14, andthe data exchange required is a remote write, i.e. a reading of the data stored in the first physical addressing space of the memory16wherein the first software process is executed and a writing of this data in the second physical addressing space of the memory38wherein the second software process is executed.

In this embodiment, the presence of the controller DMA20and of its IOMMU28is necessary. By symmetry, the presence of the controller DMA42and of its IOMMU50is also necessary if a data exchange is considered of which the request is sent at the initiative of the second software process of the second circuit34. The communications managed by the DMA controller are carried out according to the RDMA programming model, without it being necessary to provide details on the operation of this well-known model in the rest of the description.

The first step of negotiating200of the creation phase of the communication channel of this second embodiment is identical to the step100described hereinabove.

During a following step of configuring202the creation phase of the communication channel, the IOMMU28of the DMA controller20of the first circuit12is configured to carry out a translation of the virtual addressing space of the first software process into its physical addressing space in association with the communication channel negotiated, i.e. in association with the memory context (LIDSRC, KEYSRC). Likewise, the IOMMU52of the second circuit34is configured to carry out a translation of the virtual addressing space of the second software process into its physical addressing space in association with the communication channel negotiated, i.e. in association with the memory context (LIDDEST, KEYDEST). Furthermore, the IOMMU28of the DMA controller20of the first circuit12is configured to carry out a translation of the virtual addressing space of the second software process into a temporary physical addressing space, representing the physical addressing space of the second software process as viewed from the first circuit12. Finally, the LUT32of the first circuit12is configured to associate this temporary physical addressing space to the memory context (LIDDEST, KEYDEST) that can be used by the second circuit34.

Then, during a step204, the first software process sends a remote write request, with this request designating a first virtual address IOVASRCof data to be read in the first virtual addressing space of the first software process and a second virtual address IOVADESTwherein to write the data read, with this second virtual address IOVADESTbeing included in the second virtual addressing space of the second software process. These two virtual addresses IOVASRCand IOVADEST, which can be used by the controller DMA20and its IOMMU28, are handled by the DMA controller20.

More precisely, the first virtual address IOVASRC, coded over 32 bits, is encapsulated in a more complete virtual address VASRCcoded over 64 bits which further comprises the parameter KEYSRCcoded over 16 bits and a complement at 0:

More precisely also, the second virtual address IOVADEST, coded over 32 bits, is encapsulated in a more complete virtual address VADESTcoded over 64 bits which further comprises the parameter IKEYDESTdefined hereinabove, and a complement at 0:

During a following step206, the virtual address IOVASRCis translated by the IOMMU28into the physical address PASRCdefined hereinabove thanks to the memory context (LIDSRC, KEYSRC) which is known to the DMA controller20.

Then, during a read step208, the data to be read in the local memory16is read by the DMA controller20without invoking the main processor14.

During a following step210, the virtual address VADESTis translated by the IOMMU28into the temporary physical address TPADESTdefined hereinabove. The translation consists in this embodiment in simply suppressing the 16 most significant bits of VADESTand in setting the 48thbit to 1.

The following steps212to218are identical to the steps112to118of the preceding embodiment.

The path of the read and write access of the method ofFIG. 3Ais shown inFIG. 38. Note that none of the main processors14and36is invoked. It is further noted that no particular network adapter is invoked.

Note that it is simple, as in the first embodiment, to adapt the method described hereinabove to a remote read or for a data exchange of which the request would be sent at the initiative of the second software process of the second circuit34.

As such, by symmetry, during the step of configuring202, the IOMMU50of the DMA controller42of the second circuit34can be configured to carry out a translation of the virtual addressing space of the second software process into its physical addressing space in association with the communication channel negotiated, i.e. in association with the memory context (LIDDEST, KEYDEST). Likewise, the IOMMU30of the first circuit12can be configured to carry out a translation of the virtual addressing space of the first software process into its physical addressing space in association with the communication channel negotiated, i.e. in association with the memory context (LIDSRC, KEYSRC). Furthermore, the IOMMU50of the DMA controller42of the second circuit34can be configured to carry out a translation of the virtual addressing space of the second software process into a temporary physical addressing space, representing the physical addressing space of the first software process as viewed from the second circuit34. Finally, the LUT54of the second circuit34can be configured to associate this temporary physical addressing space to the memory context (LIDSRC, KEYSRC) which can be used by the first circuit12.

A third embodiment of the Invention, also shown by theFIGS. 3A and 3B, differ from the preceding only in that the virtual addresses of the DMA controller20are coded over 32 bits (those of the main processor14which can be coded over 64 or 32 bits) and the physical addresses over 40 bits.

In this case, during the step204, the first virtual address IOVASRCis not coded over 32 bits but over 24 bits only. It is encapsulated in the more complete virtual address VASRCcoded over 32 bits which further comprises a compressed version CKEYSRCthe parameter KEYSRC, coded over 8 bits:

In this case also, the second virtual address IOVADESTis also coded over 24 bits. It is encapsulated in the more complete virtual address VADESTcoded over 32 bits which further comprises a compressed version CKEYDESTof the parameter KEYDEST, coded over 8 bits:

In this case also, during the step210, the virtual address VADESTcoded over 32 bits is translated by the IOMMU28into a temporary physical address TPADESTcoded over 40 bits. The translation consists in this embodiment in recovering the parameter IKEYDESTdefined hereinabove using the compressed parameter CKEYDESTthen in completing the last 4 bits with “1 0 0 0”:

In this case also, during the step212, the transport address TADEST, obtained by translation of the temporary physical address TPADESTusing the LUT32, is coded over 40 bits:

In this case also, during the step216, the address PADESTobtained by translation of the transport address TADESTusing the IOMMU52, is coded over 40 bits.

As with the second embodiment, the first embodiment could also be adapted to virtual addresses coded over 32 bits and physical addresses over 40 bits by adapting its steps100to118in accordance to what was done for the third embodiment. Generally, note that the coding of virtual addresses over 32 or 64 bits is relatively standard, with coding over 64 bits being widespread in the processors. On the other hand, the number of bits over which the physical addresses can be coded is clearly freer. It was chosen, in the preceding embodiments, to code them over 40 or 48 bits but other choices could have been made.

A fourth embodiment of the invention, also shown inFIGS. 3A and 3B, differs from the preceding one only in that the two software processes concerned by the request to exchange data are executed on virtual machines of the main processors14and36.

In this case, the step206is adapted to recover the physical address PASRCin two successive translations carried out by the IOMMU28. A first translation, carried out on the virtual machine which executes the first software process in the first circuit12, makes it possible to translate the virtual address VASRCover 32 bits into an intermediate physical address IPASRCover 40 bits. A second translation, carried out on the hypervisor which executes this virtual machine, makes it possible to translate the intermediate physical address IPASRCinto the physical address PASRCcoded over 40 bits.

In this case also, the step210is adapted to recover the temporary physical address TPADESTin two successive translations carried out by the IOMMU28. A first translation, carried out on the virtual machine that executes the first software process in the first circuit12, makes it possible to translate the virtual address VADESTover 32 bits into an intermediate temporary physical address ITPADESTover 40 bits wherein the parameter IKEYDESTwas translated into a virtualized parameter VIKEYDEST:

A second translation, carried out on the hypervisor which executes this virtual machine, makes it possible to translate the intermediate temporary physical address ITPADESTinto the temporary physical address TPADEST.

In this case also, the step216is adapted to recover the physical address PADESTin two successive translations carried out by the IOMMU52. A first translation, carried out on the virtual machine that executes the second software process in the second circuit34, makes it possible to translate the transport address TADESTinto an Intermediate physical address IPADESTover 40 bits. A second translation, carried out on the hypervisor which executes this virtual machine, makes it possible to translate the intermediate physical address IPADESTinto the physical address PADESTcoded over 40 bits.

In this case also, note that the manager of the first access port of the first circuit12is the hypervisor of the main processor14.

As with the third embodiment, the first and second embodiments could also be adapted to executions of their software processes on virtual machines by adapting their steps in accordance with what was done for the fourth embodiment.

It clearly appears that a method for executing a request to exchange data such as one of those described hereinabove makes it possible, via cunning executed in the steps112and212described hereinabove, reading or writing of data remotely, i.e. from a circuit on a card or chip to the other in a system of interconnected circuits, without invoking the processor of the remote circuit and without any need for network adaptation.

Furthermore, it is advantageous to be able to take advantage of the memory management units that are dedicated to input/output and virtualization technologies in order to implement a method according to the invention.

Furthermore, in the embodiments described in reference toFIGS. 3A and 3B, it is advantageous to be able to use the RDMA programming model and consequently to benefit from the corresponding software libraries and from the OFED™ (“OpenFabrics Enterprise Distribution”) programming interface on low-consumption circuits that do not comprise controllers in accordance with the Infiniband or RoCE protocol.

Note moreover that the invention is not limited to the embodiments described hereinabove. It will indeed appear to those skilled in the art that various modifications can be made to the embodiments described hereinabove, in light of the teaching that has just been disclosed to them. In the claims that follow, the terms used must not be interpreted as limiting the claims to the embodiments exposed in this description, but must be interpreted in order to include therein all of the equivalents that the claims aim to cover due to their formulation and of which the foresight is within the scope of those skilled in the art by applying their general knowledge to the implementation of the teaching that has just been disclosed to them.