WO2023180148A1 - Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés - Google Patents

Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés Download PDF

Info

Publication number
WO2023180148A1
WO2023180148A1 PCT/EP2023/056678 EP2023056678W WO2023180148A1 WO 2023180148 A1 WO2023180148 A1 WO 2023180148A1 EP 2023056678 W EP2023056678 W EP 2023056678W WO 2023180148 A1 WO2023180148 A1 WO 2023180148A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
identifier
cache memory
nic
network card
Prior art date
Application number
PCT/EP2023/056678
Other languages
English (en)
Inventor
Yoann GHIGOFF
Kahina LAZRI
Gilles Muller
Julien SOPENA
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2023180148A1 publication Critical patent/WO2023180148A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the present invention relates to the fields of computer networks and information storage. More particularly, the present invention relates to a method for processing data access requests, and also to an entity, a computer program, and an associated information medium.
  • the present invention finds a particularly advantageous application, although in no way limiting, for the implementation of network or network data storage applications, for example network cache applications.
  • data storage devices in computer networks are essential components for the implementation of network applications and Internet services. Such devices are all the more critical for the large-scale deployment of network applications, as they must process a high number of requests and provide access to data with low latency, particularly for frequently requested data. .
  • load sharing devices In order to reduce the load on network equipment, it is known to use load sharing devices. Load balancing devices distribute all tasks across a set of resources. In this case, such devices can be used to distribute the network load and requests between several pieces of equipment in a network application, which makes it possible to alleviate the risks of congestion.
  • load distribution devices has the disadvantage of requiring an oversizing of the number of network equipment, which leads to underutilization of the latter.
  • dedicated network equipment optimized for data storage and comprising specialized network stacks.
  • such dedicated network equipment may incorporate operating system kernel bypass mechanisms (or “kernel-bypass” in English).
  • kernel bypass mechanisms or “kernel-bypass” in English.
  • kernel bypass mechanisms make it possible to improve network performance by avoiding performance costs, such as processing times and latencies, linked to the generic nature of standard operating systems.
  • this type of solution requires exclusive access to a network card, which then makes it impossible to share the network card and hardware resources with other applications requiring network access.
  • implementing a kernel bypass mechanism is not transparent to a network application. Indeed, to implement a kernel bypass mechanism, it is necessary to significantly modify the network application, in particular by incorporating specific network functions and by executing programs from dedicated libraries.
  • a cache memory may be integrated between the network interface and the data storage application.
  • the storage device is therefore able to process certain requests using the data recorded in the cache memory. Processing a request using the cache memory makes it possible to reduce the processing time of the request by the storage device.
  • the data access latency is not entirely satisfactory. In order to implement large-scale network applications, it is necessary to further reduce data access latency and increase the throughput of processed requests.
  • the present invention aims to remedy all or part of the disadvantages of the prior art, in particular those explained above.
  • a method for processing requests for access to data, the method being implemented by an entity connected to a network, said entity comprising a card network and an operating system kernel.
  • the process includes steps of: • interception by the network card of a network packet intended for an application configured to process and respond to said access requests, said network packet carrying a read request comprising a data identifier;
  • requests By “data access requests”, reference is made here to requests for access to write or read computer data. Typically, requests may be issued by client devices and transmitted over a communications network.
  • cache memory By “cache memory”, reference is made here to a memory which records copies of data from an application in order to reduce the access time to this data.
  • kernel By “kernel”, reference is made here to an operating system kernel (or “kernel” in English) and thus to a computer program making it possible to manage the resources of a computer and allowing the different components, hardware and software, to communicate with each other.
  • the steps implemented by the kernel are performed in kernel space.
  • the steps implemented by the kernel are carried out by the computer drivers (or “in-kernel drivers” in English) of the network card, the computer drivers being installed in the kernel.
  • the application By “application”, reference is made here to a computer program implemented in user space, thus relying on the abstraction mechanisms provided by the kernel. In the context of the present invention, and differently from the steps implemented by the kernel, steps implemented by the application are carried out in the user space.
  • the application may be a network data storage application.
  • the step of transmitting a read request to the kernel is carried out depending on the presence of data corresponding to the identifier in the first cache memory. For example, if the network card understands the requested data, the network card processes the request and therefore does not transmit it to the kernel. According to another example, if the first cache memory does not include the requested data, the network card transmits the request to the kernel.
  • the response to a read request is determined based on the presence of data corresponding to the identifier in the cache memories. For example, if one of the cache memories includes the requested data, the response sent includes the data read in this cache memory. According to another example, if the identifier does not correspond to any data in the application, the response sent may be an error message.
  • the proposed invention consists of a hierarchical architecture of cache memories on several levels of a computer system.
  • This multi-cache architecture comprising a first level of cache implemented by the network card and a second level of cache implemented by the kernel, aims in particular to accelerate the latency linked to network accesses for reading data from an application .
  • requests are processed at the lowest possible level, either by the network card or by the kernel. If a data read request cannot be processed by the first cache level implemented by the network card, the request is transmitted to the second cache level implemented by the kernel.
  • the first and second cache levels make it possible to accelerate the processing of data access requests.
  • the network card is configured to process and respond to a request received in a network packet and includes the first cache level. Processing a request by the network card avoids its transfer to the kernel and thus reduces processing latency. Processing a request by the network card further saves processing resources since processing of the network packet by the kernel is not necessary.
  • the kernel is configured to process and respond to a request and includes the second level of cache. For example, the kernel is configured to process requests by intercepting network packets at the computer drivers of the network card.
  • computer drivers include an attachment point (known as a "hook" in English) allowing specific processing to be programmed on received network packets, which makes it possible to modify the default processing of network packets carried out by the core.
  • an attachment point known as a "hook” in English
  • Processing a request by the kernel avoids its transfer to the application and therefore reduces processing latency and saves processing resources since the request is not processed by the application
  • the proposed method By processing read requests at the network card level or at the kernel level, the proposed method makes it possible, among other things, to reduce the data access latency, to increase the number and throughput of requests processed and to minimize the use of processing resources.
  • the proposed process thus makes it possible to alleviate the risks of congestion.
  • the proposed method allows efficient use of the entity's hardware and software resources and sharing them with other applications.
  • the implementation of the first cache level at the network card level and the second cache level at the kernel space level is transparent for the application which runs in user space.
  • implementing and operating the first and second cache levels does not require any modification to the application.
  • the transmission of the request by the network card to the core is carried out if the first cache memory does not include data corresponding to the identifier included in the read request. Furthermore, if the first cache memory includes data corresponding to the identifier, then the response to the request includes said data read in the first cache memory; or, if the second cache memory includes data corresponding to the identifier included in the read request, said response includes said data read in the second cache memory.
  • This embodiment ensures the reliability of responses to read requests issued by the entity. Indeed, according to this embodiment, a read request is only processed by the network card if the first cache memory includes data corresponding to the identifier included in the request.
  • the request processing method comprises, if none of said cache memories includes data corresponding to said identifier, a step of transmitting the read request to the application, the response emitted by the network card comprising data corresponding to said identifier, this data being transmitted by the application in response to the read request.
  • This embodiment makes it possible to guarantee certain processing of read requests. If a cache level does not include the requested data, it will necessarily transmit the request to the higher level; and if none of the first and second cache levels are able to process the read request, then it is processed by the application. Steps implemented by the application are performed at the user space level, while steps implemented by the kernel are performed at the kernel space level.
  • the request processing method comprises an exception mechanism allowing a cache level to transmit a request to the higher level, if this cache level is not able to process the request. request.
  • a read request is only transmitted by a cache level to a higher level if the memory of this cache level does not include the requested data.
  • the application is configured to manage concurrent access. For example, the application is able to process several write requests issued by different client devices and relating to the same data, and a read request relating to this data. Thus, following one or more write requests, data recorded in one of the cache memories may no longer be identical to the data in the application corresponding to the same identifier. It is then necessary to take into account the validity of data recorded in cache memories to process and respond to requests.
  • the read request is transmitted by the network card to the core if the first cache memory does not include valid data corresponding to said identifier; and the read request is transmitted by the kernel to the application if none of said cache memories includes valid data corresponding to said identifier. Furthermore, according to this embodiment, said response sent by the network card includes valid data corresponding to said identifier.
  • valid data reference is made here, for a certain identifier, to data which can be used to respond to a read request comprising this identifier.
  • valid data is necessarily identical to the data of the application associated with the same identifier.
  • invalid data we refer here, for a certain identifier, to data which cannot be used to respond to a read request including this identifier.
  • invalid data is not necessarily identical to the application data associated with the same identifier.
  • This embodiment makes it possible to take into account the validity of the data recorded in the cache memories to process requests and respond to them.
  • this embodiment makes it possible to implement processing of requests by the different cache levels depending on the consistency of the data recorded in the cache memories with the application data.
  • this embodiment by taking into account the validity of the data, can also be advantageous for implementing a data expiration mechanism.
  • the response to a read request includes said valid data corresponding to the identifier included in the request. Indeed, if the application includes data corresponding to the identifier included in the read request received, the response to a read request includes the requested data.
  • This embodiment ensures the reliability of responses to read requests issued by the entity. If the application includes data corresponding to the identifier of the read request, then the data corresponding to the identifier is transmitted by the entity in the response to the request. Thus, for client devices issuing requests, access to application data presents, in addition to reduced latency, reliability in processing requests by the entity.
  • the requests for access to data and/or the responses to the requests are transmitted via a computer network implementing an IP network protocol (acronym for the English expression -Saxon “Internet Protocol”).
  • IP network protocol an IP network protocol
  • the use of the IP protocol makes it possible to route data packets between a client device and the request processing entity.
  • the IP protocol makes it possible to efficiently route packets in a computer network implementing a “best-effort” transmission mechanism (or more commonly referred to by the Anglo-Saxon expression “best-effort delivery”).
  • the read requests and/or the responses to the read requests are transmitted via a computer network implementing a UDP transport protocol (acronym for the English expression Saxon “User Datagram Protocol”).
  • UDP protocol makes it possible to transmit read requests and/or their responses simply and quickly between a client device and the request processing entity.
  • Data transmission with the UDP protocol does not require any prior communication to establish the connection between a client device and the request processing entity and does not involve retransmissions, which allows reducing data access latency.
  • the network packets intercepted by the network card are the network packets whose destination port corresponds to the port of the application.
  • the request processing method further comprises a step of:
  • This embodiment makes it possible to record data in the cache memories.
  • the kernel uses a mechanism to intercept data sent in response to read requests to potentially save them in caches based on their identifiers.
  • the kernel records or not an intercepted data depending on its identifier.
  • the kernel can save data in a cache memory, if this data is frequently requested.
  • This embodiment makes it possible in particular to ensure consistency between the cache memory data and the application data.
  • the interception mechanism allows data to be recorded without requiring additional processing and data exchange between the different cache levels and the application.
  • the recording of data in the first cache memory is carried out by the kernel, which frees up processing resources at the network card level. [0037]
  • the recording in one of the cache memories of the data included in the response to a read request is carried out if the cache memory includes invalid data or no data corresponding to the identifier included in the read request.
  • An advantage of this embodiment is to allow the recording of data in the cache memory or the updating of the data recorded in a cache memory.
  • one of the cache memories includes data corresponding to the identifier of the read request and this data is invalid, then the data transmitted in response to the request is used to update the data in the cache memory.
  • updating the data corresponding to the identifier included in the read request is carried out by intercepting the data sent in response to the read request. This interception mechanism makes it possible to update data in a cache memory without requiring additional processing and exchange of data between the different cache levels and the application.
  • the cache memories of the first and second cache levels are of limited sizes. It is therefore essential to save frequently requested application data in cache memories, which makes it possible to increase the number of requests processed by the network card or the kernel and thus effectively reduce data access latency. .
  • the memory entry to use is determined on the basis of the identifier of the data to be stored. However, different identifiers can be associated with one and the same memory entry. Then, several pieces of data compete to be recorded in this same memory entry. Considering a memory entry for which several data items compete, recording the most frequently requested data item in the memory entry makes it possible to reduce data access latency.
  • the recording in one of the cache memories of the data transmitted by the application in response to a read request is carried out based on a comparison between the identifier included in the read request and an identifier of data recorded in the cache memory.
  • the identifier included in the read request and the identifier of the recorded data are associated with one and the same cache memory entry. The data included in the response and the recorded data are thus competing data for the same memory entry.
  • the recording in one of the cache memories of the data included in the response to a read request is carried out as a function of a comparison between a threshold and a counter associated with data recorded in the cache memory.
  • the data included in the response and the recorded data are concurrent data for the same memory entry.
  • An advantage of these embodiments is to maintain frequently requested data in the first cache memory and the second cache memory while preventing these from being replaced by less frequently accessed data.
  • this embodiment makes it possible to minimize the complexity of the processing to select the data to be recorded in the different cache levels and not to increase the latency of access to the application data.
  • the data recorded in a cache memory are the data requested by the greatest number of read requests over a determined period.
  • At least one of the cache memories comprises a hash table
  • the request processing method comprises a step of:
  • the hash for indexing data in the hash table is determined on the basis of the identifier of the data and a Fowler-Noll-Vo-1A hash function, more commonly designated by the acronym FNV-1A.
  • An advantage of this particular embodiment is that the FNV-1A hashing function makes it possible in particular to determine the hash of an identifier while reading the identifier in the request, thus making it possible to reduce the latency due to the processing of queries and more generally to gain performance compared to a hash calculation carried out a posteriori.
  • the cache memory of the network card and the cache memory of the kernel are of different sizes. Specifically, the NIC cache size is smaller than the kernel cache size.
  • the request processing method comprises steps of:
  • An advantage of these particular embodiments is to guarantee the processing of write requests by the application, thus making it possible to guarantee that the application data remains up to date.
  • the application is configured to handle concurrent write and read access. For example, the application is configured to process two write requests relating to the same data and issued by different client devices, then a read request relating to this data.
  • this embodiment makes it possible to contribute to the management of concurrent access.
  • the request processing method further comprises a step of:
  • This particular embodiment makes it possible to acknowledge receipt of the write request to the client device issuing the request, and thus to signal to the client device the processing of the write request.
  • the write requests and/or the responses to the write requests are transmitted via a computer network implementing a TCP transport protocol (acronym for the expression Anglo-Saxon “Transmission Control Protocol”).
  • This particular embodiment makes it possible to implement reliable data exchanges between a client device and a request processing entity in the computer network, and thus to guarantee the delivery of write requests and/or responses. to writing requests.
  • the application processes the write request. Processing of the write request by the application may or may not result in a modification of the application data associated with this identifier. If a cache memory includes data associated with this identifier, then the recorded data may: either correspond to a previous and obsolete version of the application data; or be identical to the application data. Thus, the data recorded in the cache memory is not necessarily identical to the application data. It is then necessary to invalidate the data recorded in the cache memory so that it is not used to respond to a read request.
  • the request processing method comprises a step of:
  • This particular embodiment makes it possible to help guarantee the consistency of the data from the first and second cache memories with the application data.
  • the fact of invalidating the corresponding data in the different cache levels following a write request ensures that obsolete data is not transmitted in response to a read request.
  • write requests, before being delivered to the application are used by the network card and the kernel to invalidate the entries of the different cache levels.
  • Data can be invalidated in a cache memory by setting a validity indicator associated with the data to a zero value. Conversely, valid data can be associated with a validity indicator of non-zero value.
  • the request processing method comprises a step of:
  • the request processing method comprises a step of: recording a second computer program in the kernel, the second computer program comprising instructions for implementing the steps carried out by the core of a request processing method as described- above, when the second computer program is executed by a second processor.
  • an entity for processing data access requests the entity being connected to a network, the entity comprising a network card and a system core.
  • the network card comprising a first cache memory
  • the core comprising a second cache memory
  • said entity comprising:
  • a network reception module included in the network card to intercept a network packet intended for an application configured to process and respond to said access requests, said network packet carrying a read request comprising a data identifier
  • said entity comprises:
  • the first determination module included in the network card is configured to determine the presence and validity of data corresponding to an identifier in the first cache memory.
  • the second determination module included in the core is configured to determine the presence and validity of data corresponding to an identifier in the second cache memory.
  • the entity further comprises an application, the application comprising an application memory for recording the application data, the entity further comprising: • a second transmission module included in the core to transmit the request to the application;
  • the request processing entity is a DNS server (acronym for the Anglo-Saxon expression “Domain Name System”), the application data being for example IP addresses and the identifiers being URLs (acronym for the Anglo-Saxon expression “Uniform Resource Locator”).
  • said entity is a key server, comprising for example key-value pairs.
  • a client device connected to a network comprising:
  • a computer program comprising instructions for implementing the steps of the request processing method as described above when the instructions are executed by one or more processors .
  • the computer program can be made up of one or more sub-parts stored in the same memory or in separate memories.
  • the program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the computer program comprises eBPF code instructions (acronym for the Anglo-Saxon expression “extended Berkeley Packet Filter”).
  • eBPF technology makes it possible to use eBPF technology to develop the different cache levels.
  • eBPF technology makes it possible in particular to execute code instructions in kernel space during the execution of computer drivers, for example by exploiting a computer driver attachment point as described above.
  • a computer-readable information medium comprising a computer program as described above.
  • the information carrier can be any entity or device capable of storing the program.
  • the support may comprise a storage means, such as a non-volatile memory or ROM, for example a CD-ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a floppy disk or a hard disc.
  • the storage medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by a telecommunications network or by a computer network or by other means.
  • the program according to the invention can in particular be downloaded onto a computer network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question.
  • Figure IA schematically represents examples of data access requests between client devices and a data access request processing entity according to a particular embodiment
  • Figure IB schematically represents examples of data access requests between a client device and a data access request processing entity according to a particular embodiment
  • Figure IC schematically represents examples of data structures included in a data access request processing entity according to a particular embodiment
  • Figure 2A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 2B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • FIG 3A Figure 3A schematically represents an example of functional architecture of a data access request processing entity according to a particular embodiment
  • Figure 3B schematically represents an example of software and hardware architecture of a data access request processing entity according to a particular embodiment
  • Figure 4 represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 5A schematically represents an example of functional architecture of a data access request processing entity according to a particular embodiment
  • Figure 5B schematically represents an example of software and hardware architecture of a data access request processing entity according to a particular embodiment
  • Figure 6A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 6B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 6C represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 7A schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment
  • Figure 7B schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment
  • Figure 7C schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment
  • Figure 8A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 8B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • Figure 8C represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment
  • FIG 9 schematically represents steps of a method for processing data access requests according to a particular embodiment
  • the present invention relates to a method for processing data access requests, an entity, a computer program, and an associated information medium.
  • Figure IA schematically represents examples of data access requests between client devices and a data access request processing entity according to a particular embodiment.
  • the CLT client devices are connected via a computer communication network NET to a SERV entity for processing data access requests.
  • the SERV entity includes data from an application.
  • the SERV entity may be a network data storage server.
  • the SERV entity can also implement a DNS server for resolving domain names including URLs and IP addresses.
  • the SERV entity may implement a key server comprising key-value pairs.
  • the APP application is a key-value pair storage application and can for example be the Memcached application, an application well known to those skilled in the art and commonly deployed.
  • CLT client devices can be user equipment, mobile terminals, communicating objects, application servers, or any other device issuing data access requests.
  • the data access requests issued by the CLT client devices are SET write access requests for data in the SERV entity, or GET read access requests for data in the entity.
  • the request processing entity SERV receives requests for access to write or read data GET, SET from the client devices CLT and processes these requests.
  • the SERV entity can send REPJ3ET responses to data access requests GET, SET to the CLT client devices.
  • the computer communication network can be of the Internet type, for example implementing the IP transport protocol, the means of communication of the CLT client devices and the SERV entity relying on in particular on a communication interface capable of data exchange.
  • No limitation is attached to the nature of the communication interface between the CLT client devices and the SERV entity, which can be wired or non-wired, and can implement any protocol known to those skilled in the art (Ethernet , Wi-Fi, Bluetooth, 3G, 4G, 5G, 6G, etc.).
  • the computer network is not limited to an Internet network, any other network (proprietary, etc.) can be considered, so that the request processing entity SERV can be accessible via the NET network.
  • Figure IB schematically represents examples of data access requests between a client device and a data access request processing entity according to a particular embodiment.
  • the GET_A, SET_B data access requests are sent by a CLT client device to the request processing entity SERV.
  • Data access requests may be GET_A read access requests for data, and also be SET_B write access requests for data.
  • a GET_A read request issued by a CLT client device to the SERV entity includes an ID_A identifier of D_A data.
  • an identifier can be a URL and a piece of data can be an IP address.
  • the SERV entity issues a REP_GET_A response.
  • the REP_GET_A response may include the D_A data requested by the CLT client device or may include an ERR error message.
  • An ERR error message can be transmitted when the SERV entity does not understand the requested data, or is not able to process a request, for example following a malfunction, a congestion state, etc.
  • a SET_B write request issued by a CLT client device to the SERV entity includes an identifier ID_B of a piece of data to be written D_B, and possibly the data to be written D_B.
  • the ID_B identifier may be the same or different from the ID_A identifier.
  • the SERV entity may or may not issue a REP_SET_B response to the CLT client device.
  • the REP_SET_B response may for example include an ACK acknowledgment of receipt.
  • the data read access requests GET_A and their responses REP_GET_A are transmitted via the computer network NET implementing an IP network protocol and a UDP type transport protocol.
  • the UDP transport protocol allows data to be transmitted simply and quickly between two entities in unconnected mode.
  • the data write access requests SET_B and their responses REP_SET_B are transmitted via the computer network NET implementing an IP network protocol and a TCP type transport protocol.
  • Figure IC schematically represents examples of data structures included in a data access request processing entity according to a particular embodiment.
  • the reference sign D_A designates data corresponding to the identifier ID_A
  • the reference signs D_A1, D_A2, D_A3 designate valid data corresponding to the identifier ID_A and recorded respectively in a first cache memory Cl, a second cache memory C2, and a memory C3 of the APP application
  • the reference sign D_A1' designates data corresponding to the identifier ID_A and invalid in the first cache memory Cl.
  • data D_A1, D_A2, D_A3 of the entity SERV is identified by an identifier ID_A.
  • the SERV entity may include several memories C1, C2, C3.
  • the SERV entity may comprise: a NIC network card comprising a first cache memory Cl and an operating system core KER comprising a second cache memory C2.
  • the data stored in the first cache memory C1 and in the second cache memory C2 are data replications of the APP application.
  • the SERV entity may further comprise the APP application, located in an application layer of the SERV entity and implemented in the user space, the APP application comprising the application memory C3.
  • the APP application is configured to process and respond to GET_A, SET_B access requests, and in particular to manage concurrent access.
  • the APP application is able to process several write requests SET_B issued by different CLT client devices and relating to the same data D_B, and a read request GET_A relating to this data D_B.
  • the SERV entity ensures coherence between the data in the cache memories C1, C2 and the data of the APP application.
  • the SERV entity identifies the data D_A1, D_A2 included in the cache memories Cl, C2 either as being valid D_A1, D_A2, or as being invalid D_A1', D_A2 '.
  • valid data D_A1, D_A2 is necessarily identical to data D_A3 of the APP application and can be used to respond to a read request GET_A including the identifier ID_A.
  • invalid data D_A1', D_A2' is not necessarily identical to data D_A3 of the APP application and cannot be used to respond to a GET_A read request including the identifier ID_A.
  • Figure 2A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the method is implemented by the SERV entity connected to the NET network. As illustrated in Figure 2A, the method comprises the steps described below.
  • the steps carried out by the NIC network card are differentiated from the steps carried out by the KER core.
  • the NIC implements the steps whose reference signs start with the letter N, while the KER kernel implements the steps whose reference signs start with the letter K.
  • the NIC network card intercepts a network packet intended for the APP application, the network packet carrying a GET_A read request.
  • the GET_A request includes an identifier ID_A of data to be read D_A.
  • the NIC network card filters all packets received from the network by inspecting their destination port in order to process only requests intended for the APP application.
  • step N30 the NIC network card determines whether the GET_A request must be transmitted to the KER core based on the presence of data D_A1 corresponding to the identifier ID_A in the first cache memory Cl of the network card NIC. If yes, the process continues at step N50, otherwise at step N130.
  • step N50 the NIC network card transmits the read request GET_A to the KER core.
  • step N130 the NIC network card sends a response REP_GET_A to the read request GET_A.
  • the REP_GET_A response sent is determined based on the presence of data corresponding to the identifier ID_A in the first cache memory C1 of the network card NIC or in the second cache memory C2 of the KER core.
  • the NIC network card determines in step N30 whether the first cache memory C1 includes a memory entry for the identifier ID_A. If the first cache memory C1 does not include a memory entry for the identifier ID_A, the network card NIC transmits the GET_A request to the KER core in step N50.
  • the NIC network card determines in step N30 whether the first cache memory C1 includes data D_A1 corresponding to the identifier ID_A. If the first cache memory Cl includes the requested data D_A1, it is not necessary to transmit the GET_A request to the KER core. The NIC network card transmits in step N130 the response REP_GET_A including the data D_A1 read in the first cache memory Cl. And, if the first cache memory Cl does not include the requested data D_A1, the NIC network card transmits in step N50 the GET_A request to the KER kernel.
  • the KER core processes the GET_A request based on the presence of data D_A2 corresponding to the identifier ID_A in the second cache memory C2.
  • the processing of the GET_A request by the KER kernel can be analogous to the processing implemented by the NIC network card described above.
  • the response REP_GET_A sent in step N130 is determined according to the presence of the requested data D_A2 in the second cache memory C2
  • the transmission step N50 is carried out depending on the presence of data D_A1 corresponding to the identifier ID_A in the first cache memory Cl; and the REP_GET_A response to the GET_A request issued by the SERV entity is determined according to the presence of data D_A1, D_A2 corresponding to the identifier ID_A in the first memory C1 or in the second cache memory C2.
  • Figure 2B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment. As illustrated in Figure 2B, the method comprises the steps described below.
  • the NIC network card receives, on its network interface and from a CLT client device connected to the NET network, a network packet carrying a read request GET_A, the request GET_A comprising an identifier ID_A of data to read D_A.
  • step N20 the NIC network card intercepts the network packet carrying the read request GET_A.
  • step N30 the NIC network card determines whether the first cache memory C1 includes valid data D_A1 corresponding to the identifier ID_A.
  • step N40 the network card NIC reads the valid data D_A1 in the first cache memory Cl. Processing of the read request GET_A by the network card NIC allows you to avoid transferring the request to the KER core. The process continues in step N130.
  • step N50 the network card NIC transmits the read request GET_A to the KER core.
  • step K60 the core KER determines whether the second cache memory C2 includes valid data D_A2 corresponding to the identifier ID_A.
  • step K70 the core KER reads the valid data D_A2 in the second cache memory C2. Processing the GET_A read request by the KER kernel avoids transferring the request to a higher level of the network stack.
  • step N130 the NIC network card sends a response REP_GET_A to the read request GET_A.
  • the REP_GET_A response can be sent to the CLT client device issuing the request and include the valid data D_A1, D_A2 corresponding to the identifier ID_A or an ERR error message.
  • the KER core transmits to the NIC network card the response REP_GET_A to the read request GET_A, this response comprising the valid data D_A2 corresponding to the identifier ID_A and read in the second cache memory C2.
  • the second level of cache implemented by the KER core is particularly suited to multi-core type architectures, the KER core being able to exploit multi-queue network cards in order to process several requests in parallel on the different cores .
  • Figure 3A schematically represents an example of functional architecture of a data access request processing entity according to a particular embodiment.
  • the SERV entity comprises a NIC network card and a KER operating system kernel.
  • the SERV entity is connected to the NET computer network via its NIC network card. Access requests GET_A, SET_B are received by the NIC network card from the NET network; and the REP_GET_A, REP_SET_B responses are sent by the NIC network card to the NET network.
  • the NIC and KER core include the modules described below.
  • module can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer or computer programs or subprograms. more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the NIC network card comprises the following modules: a network reception module MOD_RX1 for receiving and intercepting a read request GET_A comprising an identifier ID_A of data D_A; a first determination module MOD_DET1 for determining whether the first cache memory Cl includes valid data D_A1 corresponding to the identifier ID_A; a first reading module MOD_RD1 for reading the valid data D_A1 corresponding to the identifier ID_A in the first cache memory Cl; a first transmission module MOD_FWD1 for transmitting the read request GET_A to the KER core; and a network transmission module MOD_TX1 for transmitting a REP_GET_A response to the read request GET_A.
  • the NIC network card further comprises a first reception module for receiving valid data D_A2, D_A3 from the KER core.
  • the KER core comprises the following modules: a second determination module MOD_DET2 to determine whether the second cache memory C2 includes valid data D_A2 corresponding to the identifier ID_A; and a second reading module MOD_RD2 included in the KER core to read said valid data D_A2 in the second C2 cache memory.
  • the KER core further includes a second transmission module for transmitting a REP_GET_A response to a GET_A request to the NIC network card.
  • the NIC network card and the KER core are connected via a communication bus implementing the PCIe protocol (acronym for the Anglo-Saxon expression “Peripheral Component Interconnect Express ").
  • Figure 3B schematically represents an example of software and hardware architecture of a data access request processing entity according to a particular embodiment.
  • the SERV entity comprises a NIC network card and a KER operating system kernel.
  • the NIC network card includes in particular: a Cl cache memory; a PROC1 processing unit or processor; and a MEM1 memory.
  • the NIC network card includes interfaces and a communication module for on the one hand exchanging data with other devices via the NET network and on the other hand for exchanging data with the KER core.
  • the NIC network card constitutes a physical interface between the SERV entity and the NET network. The NIC network card allows you to prepare, send and control data circulating on the NET network.
  • the NIC network card is a programmable network card.
  • the NIC network card has the hardware architecture of a computer.
  • the NIC network card comprises, in particular, a processor PROC1, a RAM1 RAM1, a MEM1 read only memory and a non-volatile memory ROM1.
  • the memory MEM1 of the network card NIC constitutes an information or recording medium in accordance with the present invention, readable by computer and by the processor PROC1 and on which is recorded a computer program PROG1 conforming to the invention.
  • the computer program PROG1 includes instructions for implementing the steps carried out by the network card NIC of a method for processing data access requests, when the computer program PROG1 is executed by the processor PROC1 .
  • the computer program PROG1 defines the functional modules represented by Figure 3A of the NIC network card, which rely on or control the hardware elements of the latter.
  • the KER core notably comprises a C2 cache memory.
  • the SERV entity includes a processing unit or processor PROC2 and a memory MEM2 associated with the KER core.
  • the KER core includes an interface and a communication module for exchanging data with the NIC network card.
  • the KER core may include an interface for exchanging data with the APP application.
  • the SERV entity has the hardware architecture of a computer.
  • the KER core can thus be associated with, in particular, a processor PROC2, a RAM2 random access memory, a MEM2 read only memory and a non-volatile memory ROM2.
  • the MEM2 memory associated with the KER core constitutes an information or recording medium in accordance with the invention, readable by computer and by the PROC2 processor and on which a PROG2 computer program in accordance with the invention is recorded.
  • the PROG2 computer program includes instructions for implementing the steps carried out by the KER core of a method for processing data access requests according to the invention, when the PROG2 computer program is executed by the PROC2 processor.
  • the PROG2 computer program defines the functional modules represented by Figure 3A of the KER core, which rely on or control the hardware elements of the latter.
  • the MEM2 memory associated with the KER core can also constitute an information or recording medium in accordance with the invention, readable by computer and on which a PROG12 computer program in accordance with the invention is recorded.
  • the PROG12 computer program comprises first instructions for implementing the steps carried out by the NIC network card of a method for processing data access requests according to the invention, when the first instructions are executed by a first processor PROC1.
  • the PROG12 computer program further comprises second instructions for implementing the steps carried out by the KER core of a method for processing data access requests according to the invention, when the second instructions are executed by a second PROC2 processor.
  • the computer program PROG12 thus includes instructions for implementing the steps of a request processing method according to the invention, when the computer program is executed by a computer.
  • the PROG12 program defines the functional modules represented by Figure 3A of the NIC network card and the KER core, which rely on or control the hardware elements of the latter.
  • the computer programs according to the invention can include eBPF code instructions, eBPF technology thus being used to develop the different cache levels.
  • eBPF technology makes it possible to execute code instructions in kernel space.
  • the request processing method comprises loading or recording the computer program PROG1 in the NIC network card.
  • the computer program PROG1 can be loaded into the NIC network card by the SERV entity and executed by the NIC network card to implement a request processing method as proposed.
  • the request processing method comprises a step of loading or recording the computer program PROG2 in the KER core.
  • the computer program PROG2 can be loaded into the KER core by the SERV entity and executed by the KER core to implement a request processing method as proposed. More specifically, the PROG2 computer program can be executed by the NIC network card computer drivers installed in the KER kernel.
  • Figure 4 represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • step K60 implemented by the KER kernel, the second cache memory C2 does not include valid data D_A2 corresponding to the identifier ID_A, the KER kernel transmits to step K80 the request for reading GET_A to APP application.
  • step K90 the KER core receives a REP_GET_A response to the GET_A request from the APP application, this response comprising data D_A3 corresponding to the identifier ID_A, which is said to be valid subsequently.
  • the KER core thus intercepts the valid data D_A3 emitted by the APP application in response to the GET_A request.
  • step N120 the NIC network card receives the REP_GET_A response from the KER core and transmits this response to step N130 described previously.
  • Figure 5A schematically represents an example of functional architecture of a data access request processing entity according to a particular embodiment.
  • the NIC network card comprises, in comparison with the architecture illustrated in Figure 3A, the following additional modules: a first reception module MOD_RCV1 for receiving data from the KER core valid D_A2, D_A3 corresponding to the identifier ID_A.
  • the KER core comprises, in comparison with the architecture illustrated in Figure 3A, the following additional modules: a second transmission module MOD_FWD2 for transmitting the GET_A request to the APP application ; and a second reception module MOD_RCV2 for receiving a REP_GET_A response from the APP application and intercepting the valid data D_A3 corresponding to the identifier ID_A included in this response.
  • a second transmission module MOD_FWD2 for transmitting the GET_A request to the APP application
  • a second reception module MOD_RCV2 for receiving a REP_GET_A response from the APP application and intercepting the valid data D_A3 corresponding to the identifier ID_A included in this response.
  • the APP application comprises: an application memory
  • the APP application is integrated into the SERV entity itself.
  • the APP application can also be remotely remote and implemented by another entity, this other entity being equipped with the hardware and software components of a computer, in particular: a processor, a RAM, a ROM and non-ROM. volatile.
  • the SERV entity is thus located on an intermediate plane between a CLT client device and the APP application.
  • Figure 5B schematically represents an example of software and hardware architecture of a data access request processing entity according to a particular embodiment.
  • the SERV entity includes a NIC network card, a KER core, and an APP application.
  • the architecture illustrated by Figure 5B comprises, in comparison with the architecture illustrated by Figure 3B, the following additional hardware and software components.
  • the SERV entity includes an APP application.
  • the APP application includes a C3 memory for storing APP application data.
  • the memory MEM2 associated with the core KER constitutes an information or recording medium in accordance with the invention, readable by computer and by the processor PROC2 and on which a program is recorded PROG3 computer according to the invention.
  • the PROG3 computer program includes instructions for implementing the steps carried out by the APP application of a method for processing data access requests according to the invention, when the PROG3 computer program is executed by the second processor PROC2.
  • the PROG3 computer program defines the functional modules represented by Figure 5A of the APP application, which rely on or control the hardware elements of the latter.
  • the MEM2 memory associated with the KER core can also constitute an information or recording medium in accordance with the invention, readable by computer and on which a PROG123 computer program in accordance with the invention is recorded.
  • the computer program PROG123 includes the instructions of the computer program PROG12 and in addition the instructions of the computer program PROG3.
  • the computer program PROG123 thus includes instructions for implementing the steps of a request processing method according to the invention, when the computer program is executed by a computer.
  • the computer program PROG123 defines the functional modules represented by Figure 5A of the NIC network card, the KER core and the APP application, which rely on or control the hardware elements of the latter.
  • the data from the APP application included in the memory C3 are stored in the RAM2 RAM2 of the SERV entity and accessed by the APP application from the user space; and the data of the KER core included in the second cache memory C2 are stored in RAM2 of the SERV entity and accessed by the KER core from the core space.
  • Figure 6A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the method illustrated in Figure 6A comprises, in comparison with Figure 4, the additional steps described below.
  • step K90 the KER core intercepts a REP_GET_A response to the read request GET_A, this response comprising valid data D_A3.
  • the KER core can use the valid data D_A3 received to record new data in the cache memory Cl, C2 or replace recorded data D_C1, D_C2 in the cache memory Cl, C2.
  • step K100 the KER core can record in the second cache memory C2 the valid data D_A3 received from the APP application.
  • the KER kernel transmits to the NIC network card the REP_GET_A response to GET_A.
  • step Kl 10 the KER core can record in the first cache memory Cl the valid data D_A3 received from the APP application.
  • step N120 the NIC network card receives from the KER core the REP_GET_A response which is sent in step N130.
  • the KER core can also record in the first cache memory C1 valid data D_A2 transmitted in response to a GET_A request. Indeed, at step K70, the KER core reads the valid data D_A2 in the second cache memory C2. Following this step, the KER core can record the valid data D_A2 in the first cache memory Cl before transmitting the REP_GET_A response to the GET_A request to the NIC network card.
  • Figure 6B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the method illustrated in Figure 6B comprises, in comparison with the method illustrated in Figure 6A, the following additional steps.
  • step K101 Following step K90 of interception, by the KER kernel, of valid D_A3 data corresponding to the identifier ID_A, the KER kernel implements a step K101.
  • step K101 the kernel KER determines whether the second cache memory C2 includes invalid data D_A2' corresponding to the identifier ID_A.
  • step K102 if the second memory C2 includes the data D_A2', the core KER records in the second cache memory C2 the valid data D_A3 received from the application APP and corresponding to the identifier ID_A.
  • the KER core determines whether the first cache memory Cl includes data D_A1' corresponding to the identifier ID_A.
  • step K112 if the first memory Cl includes the data D_A1', the core KER records in the first cache memory Cl the valid data D_A3 received from the application APP and corresponding to the identifier ID_A.
  • Figure 6C represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the method illustrated in Figure 6C comprises, in comparison with the method illustrated in Figure 6A, the following additional steps.
  • step K90 of interception by the KER kernel, of valid D_A3 data corresponding to the identifier ID_A, the KER kernel implements at least one of steps K103 and K104.
  • step K103 the KER kernel compares the identifier ID_A to an identifier ID_C of a piece of data recorded D_C2 in the second cache memory C2.
  • step K104 the core KER compares a threshold THR_2 to a counter CNT_C2 associated with data recorded D_C2 in the second cache memory C2 corresponding to an identifier ID_C.
  • step K105 depending on the result of at least one of the comparisons carried out in steps Kl 03 and Kl 04, the core KER records or not the valid data D_A3 received from the application APP and corresponding to the identifier ID_A.
  • the recording in the cache memory C2 is conditioned by the results of the two comparisons described above and carried out in steps Kl 03, Kl 04.
  • the data recorded D_C2 in the cache memory C2 is replaced during recording by the valid data D_A3 received.
  • the value of a counter CNT_C2 is determined in the following manner.
  • the value of a counter CNT_C2 varies according to the number of read and write accesses to the data D_C2 in the second memory C2.
  • the counters associated with the entries are initialized to a zero value. If data recorded D_C2' in cache memory C2 is invalid, then the associated counter CNT_C2 is zero; and if the data D_C2 is valid, the associated counter CNT_C2 is greater than or equal to 1.
  • the associated counter CNT_C2 is set to 1
  • the recorded data C_2 is valid in the cache memory C2 but can be evicted by data received D_A3 in response to a GET_A request.
  • the associated counter CNT_C2 is set to a maximum value MAX_CNT2.
  • the associated counter CNT_C2 is set to the maximum value MAX_CNT2.
  • the cache memory C_2 may include a concurrent value CHA_C2 making it possible to identify concurrent data D_D.
  • the KER kernel determines a concurrent hash G2 (ID_A) based on the identifier ID_A and the hash function G2. If the counter CNT_C2 is greater than 1, and the competitor value CHA_C2 is different from the competitor hash G2(ID_A), i.e.
  • the KER core can implement a recording as described above in the first cache memory C1 of valid data D_A3 received from the APP application in response to a GET_A request.
  • the KER core implements steps K113, K114, and K115 analogous to steps Kl 03, K104, and Kl 05 described above to record valid data D_A3 in the first cache memory Cl, and using a threshold THR_1, a hash function G1 and a maximum value MAX .CNT1.
  • the different cache levels can share similar data structures and data recording methods, although they can be configured independently.
  • One of the objectives of these recording steps is to maintain frequently requested data in the cache memories C1, C2 while preventing them from being replaced by less accessed data.
  • these recording mechanisms also aim to be executable in a minimal time so as not to negatively impact query processing latency.
  • Figure 7A schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment.
  • the cache memory Cl includes in one of its entries: the identifier ID_A; the data D_A1; a validity indicator V_A1; and a counter CNT_A1.
  • the validity of data D_A1, D_A2 in one of the cache memories C1, C2 is characterized using an indicator V_A1, V_A2.
  • the indicator V_A1, V_A2 representing the validity is equal to 1; and if the data D_A1', D_A2' is invalid in the cache memory C1, C2, the indicator V_A1, V_A2 is zero.
  • the valid data reference signs D_A1, D_A2 are differentiated from the invalid data reference signs D_A1', D_A2', the latter ending with an apostrophe.
  • the validity of data D_A1, D_A2 in one of the cache memories Cl, C2 is characterized using the counter CNT_A1, CNT_A2 associated with data D_A1, D_A2.
  • the counter CNT_A1, CNT_A2 representing the validity is greater than or equal to 1; and if the data D_A1', D_A2' is invalid in the cache memory Cl, C2, the counter CNT.A1, CNT_A2 is zero.
  • Figure 7B schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment.
  • the first cache memory Cl comprises a hash table TAB1.
  • the hash table TAB1 allows a direct key-value association, i.e. ID_A-D_A and thus allows data to be found quickly, by searching for it in a location in the table TAB1 corresponding to the result of a hash function Hl.
  • the request processing method comprises according to this particular embodiment a step of determining a hash H_A1, the hash H_A1 being calculated from the identifier ID_A and the hash function Hl.
  • the H_A1 hash allows you to quickly find the data D_A1 in table TAB1.
  • the hash H_A1 can be reduced to the size of the hash table TAB1 via a modulo operation to obtain the index of the entry comprising the data D_A1 in the table TAB1.
  • the hash function H1 used is a Fowler-Noll-Vo-1A hash function, more commonly designated by the acronym FNV-1A.
  • This function makes it possible in particular to calculate the H_A1 hash while reading a request, thus making it possible to reduce latency due to request processing and more generally to gain performance compared to a hash calculation carried out a posteriori.
  • the recording of a piece of data D_A in a hash table TAB1 as described above also includes the recording of the identifier ID_A of this piece of data D_A in an entry of the hash table TAB1.
  • the entries of a TAB1 hash table are commonly called cells (or with the Anglo-Saxon expressions “buckets” or “slots”).
  • Such a data structure offers constant time complexity for search, insertion or invalidation operations of data, which makes it possible to reduce the latency due to query processing and makes it possible to process a load important with high query throughput.
  • Figure 7C schematically represents an example of data structures included in a data access request processing entity according to a particular embodiment.
  • the second cache memory C2 can include a hash table TAB2.
  • the TAB2 hash table allows a direct key-value association, i.e. ID_A-D_A.
  • the processing method according to this particular embodiment comprises a step of determining a hash H_A2, the hash H_A2 being calculated from the identifier ID_A and a hash function H2.
  • the H_A2 hash allows you to quickly find the data D_A1 in the TAB1 table.
  • the H2 hash function used is a Fowler-Noll-Vo-1A hash function, more commonly designated by the acronym FNV-1A.
  • the recording of data D_A in an entry of the TAB2 hash table also includes the recording of its identifier ID_A in the entry.
  • the table TAB2 of the second cache memory C2 includes in one of its entries: the identifier ID_A; the data D_A2; a validity indicator V_A2; a counter CNT_A2; and a competitor value CHA_A2.
  • the first cache memory C1 can include a hash table TAB1 implementing a data structure as described above.
  • the hash functions Hl, H2, Gl, and G2 and the maximum values MAX_CNT1 and MAX_CNT2 are configured differently for the first cache memory Cl and the second cache memory C2.
  • the different cache memories Cl, C2 of the architecture both aim to store the data of the APP application.
  • each cache level can be configured independently of one another in order to adapt to the hardware constraints of the different execution environments. This setting makes it possible to adjust each cache level to the available memory resources.
  • the size of the first cache memory Cl of the NIC network card may be different from the size of the second cache memory C2 of the KER core.
  • the size of the first cache memory C1 of the NIC network card is less than the size of the second cache memory C2 of the KER core.
  • Figure 8A represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the NIC network card receives a write access request SET_B comprising an identifier ID_B of a piece of data to be written D_B.
  • the SET_B request is sent by a CLT client device to the SERV entity.
  • step N240 the NIC network card transmits the write request SET_B to the KER core.
  • step K270 following receipt of the write request SET_B from the NIC network card, the KER core transmits the write request SET_B to the APP application.
  • Figure 8B represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the method illustrated in Figure 8B comprises, in comparison with the method illustrated in Figure 8A, the following additional steps.
  • step K270 the transmission by the KER core of the write request SET_B to the APP application, the KER core implements a step K280.
  • step K280 the KER core receives a response REP_SET_B to the write request SET_B including an acknowledgment of receipt ACK sent by the application APP in response to the write request SET_B. According to one embodiment, the KER core then transmits the REP_SET_B response to the NIC network card.
  • step N290 the NIC network card receives the REP_SET_B response and transmits it to step N300 to the CLT client device issuing the SET_B request.
  • FIG. 8C represents, in flowchart form, steps of a method for processing data access requests according to a particular embodiment.
  • the NIC network card receives a write access request SET_B comprising an identifier ID_B of a piece of data D_B to be written.
  • the identifier ID_B may be identical to or different from the identifier ID_A received in step N10.
  • step N220 the NIC network card determines whether the first cache memory Cl includes data D_B1 corresponding to the identifier ID_B.
  • step N230 if the first cache memory Cl includes the data D_B1, the network card NIC invalidates the data D_B1' in the first cache memory Cl, that is to say marks the data as invalid.
  • step N240 the NIC network card transmits the write request SET_B to the KER core.
  • step K250 following receipt of the write request SET_B from the network card, the core KER determines whether the second cache memory C2 includes data D_B2 corresponding to the identifier ID_B included in the write request SET_B.
  • step K260 if the second cache memory C2 includes data D_B2 corresponding to the identifier ID_B included in the write request SET_B, the kernel KER invalidates the data D_B2' in the second cache memory C2.
  • step K270 the KER core transmits the write request SET_B to the APP application.
  • Figure 9 schematically represents steps of a method for processing data access requests according to a particular embodiment.
  • Figure 9 illustrates the hierarchy of the cache memories Cl, C2 and the application memory C3, as well as the multi-level processing of access requests GET_A, SET_B.
  • the SERV entity receives from a CLT client device a GET_A request requesting read access to the data D_A, the read request GET_A comprising the identifier ID_A.
  • the NIC network card of the SERV entity intercepts the GET_A request and determines whether valid data D_A1 corresponding to the identifier ID_A is recorded in the first cache memory Cl. If so, the NIC network card is able to respond to the GET_A request and does not forward the GET_A request to the KER kernel.
  • the network card NIC reads the first cache memory Cl and transmits to the client device CLT a response REP_GET_A including the valid data D_A1.
  • the SERV entity processed and responded to the GET_A request without requesting the KER kernel or the APP application. As a result, data access latency is reduced significantly and, moreover, so is the usage of hardware and software resources.
  • the network card NIC forwards the GET_B request to the higher level, the KER core.
  • the KER kernel determines whether valid data DB_2 corresponding to the identifier ID_B is recorded in the second cache memory C2. If so, the KER core reads the data D_B2 and transmits to the NIC network card a response REP_GET_B to the read request GET_B, the response REP_GET_B comprising the valid data D_B2.
  • the NIC network card transmits the REP_GET_B response to the CLT client device.
  • the SERV entity processed and responded to the GET_B request without requesting the APP application, which reduces data access latency and saves processing resources.
  • the APP application transmits a REP_GET_C response to the GET_C read request, the REP_GET_C response including data D_C3, to the KER core, which in turn transmits it to the NIC network card.
  • the NIC network card transmits to the CLT client device.
  • the NIC network card transmits the SET_D request to the KER core; and the KER kernel transmits the SET_D request to the APP application.
  • the APP application processes the write request SET_D and records the data D_D in the application memory C3.
  • the transmission by the NIC network card and the KER core of write requests SET_D to the APP application makes it possible in particular to ensure the consistency of the data D_D between the different memories Cl, C2, C3.
  • the NIC network card and the KER core can use the write request SET_D to invalidate in the cache memories C1, C2 data D_D1', D_D2' corresponding to the identifier ID_D.
  • a method and a SERV entity for processing data access requests as proposed have the following advantages.
  • the processing and response to GET read requests by the NIC network card and the KER core makes it possible to significantly reduce the processing time of GET requests by the entity, these requests not being reported to the APP application .
  • the SERV entity is thus able to reduce access latency data in a network and increase the throughput of processed requests.
  • the processing of GET, SET requests by the NIC or KER core is transparent to the APP application. Data consistency is guaranteed between the different memories Cl, C2, C3, with only valid data being transmitted in response to GET requests.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de traitement de requêtes d'accès (GET_A) à des données, mis en œuvre par une entité (SERV) comprenant une carte réseau (NIC) et un noyau de système d'exploitation (KER), ledit procédé comprenant des étapes de : • interception (N20) par la carte réseau (NIC) d'une requête de lecture (GET_A) comprenant un identifiant (ID_A) d'une donnée (D_A); • transmission (N50) par la carte réseau (NIC) de la requête (GET_A) au noyau (KER) en fonction de la présence d'une donnée (D_A1) correspondant audit identifiant (ID_A) dans une première mémoire cache (C1) de la carte réseau (NIC); et • émission (N130) par la carte réseau (NIC) d'une réponse (REP_GET_A) à la requête (GET_A) en fonction de la présence d'une donnée (D_A1, D_A2) correspondant audit identifiant (ID_A) dans la première mémoire cache (C1) ou dans une deuxième mémoire cache (C2) du noyau (KER).

Description

Description
Titre de l'invention : Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés
Domaine technique
[0001] La présente invention se rapporte aux domaines des réseaux informatiques et du stockage d'informations. Plus particulièrement, la présente invention concerne un procédé de traitement de requêtes d'accès à des données, et également une entité, un programme d'ordinateur, et un support d'informations associés. La présente invention trouve une application particulièrement avantageuse, bien que nullement limitative, pour la mise en œuvre d'applications réseaux ou de stockage de données en réseau, par exemple des applications de cache réseau.
Technique antérieure
[0002] De manière générale, les dispositifs de stockage de données dans les réseaux informatiques sont des composants essentiels pour la mise en œuvre d'applications réseaux, et de services Internet. De tels dispositifs sont d'autant plus critiques pour le déploiement à grande échelle d'applications réseaux, ceux-ci devant traiter un nombre élevé de requêtes et fournir un accès aux données avec une faible latence, et ce en particulier pour les données fréquemment requêtées.
[0003] La mise en œuvre d'applications réseaux à grande échelle suppose toutefois de résoudre une problématique de charge sur les dispositifs de stockage de données. En effet, les dispositifs classiques, comprenant des moyens informatiques matériels et logiciels génériques, ne sont pas en mesure de traiter la totalité de la charge et des requêtes provenant du réseau avec des performances satisfaisantes. Cette situation peut conduire à une congestion du réseau au niveau des dispositifs de stockage de données et à une dégradation de la qualité de service des applications réseaux, telle qu'une latence d'accès aux données plus importante, un temps de traitement des requêtes plus long, voire le non-traitement de certaines requêtes ou la perte de données, etc.
[0004] En vue de réduire la charge au niveau d'un équipement réseau, il est connu d'utiliser des dispositifs de répartition de charge. Les dispositifs de répartition de charge distribuent l'ensemble des tâches sur un ensemble de ressources. En l'espèce, de tels dispositifs peuvent être utilisés pour distribuer la charge réseau et les requêtes entre plusieurs équipements d'une application réseau, ce qui permet de pallier les risques de congestion. Néanmoins, l'utilisation de dispositifs de répartition de charge présente l'inconvénient de nécessiter un surdimensionnement du nombre d'équipements réseaux, ce qui conduit à une sous-utilisation de ces derniers.
[0005] Afin de déployer des applications réseaux de débit d'informations élevé et de faible latence, il est également connu d'avoir recours à des équipements réseaux dédiés, optimisés pour le stockage de données et comprenant des piles réseaux spécialisées. Par exemple, de tels équipements réseaux dédiés peuvent incorporer des mécanismes de contournement du noyau de système d'exploitation (ou « kernel-bypass » en anglais). Ces piles réseaux spécialisées, et les mécanismes de contournement de noyau, permettent d'améliorer les performances réseaux en évitant les coûts en performance, tels que les temps de traitement et les latences, liés à la généricité des systèmes d'exploitation standards. Toutefois, ce type de solution requiert un accès exclusif à une carte réseau, ce qui rend alors impossible le partage de la carte réseau et des ressources matérielles avec d'autres applications nécessitant un accès réseau. De plus, la mise en œuvre d'un mécanisme de contournement de noyau n'est pas transparente pour une application réseau. En effet, pour mettre en œuvre un mécanisme de contournement de noyau, il est nécessaire de modifier de manière significative l'application réseau, notamment en y incorporant des fonctions réseaux spécifiques et en exécutant des programmes issus de librairies dédiées.
[0006] Il est également connu d'utiliser une mémoire cache pour réduire le temps d'accès à des données. Dans le cas d'un dispositif de stockage de données en réseau, une mémoire cache peut être intégrée entre l'interface réseau et l'application de stockage de données. Le dispositif de stockage est par conséquent en mesure de traiter certaines requêtes en utilisant les données enregistrées dans la mémoire cache. Le traitement d'une requête grâce à la mémoire cache permet de réduire le temps de traitement de celle-ci par le dispositif de stockage. Néanmoins, lorsque de tels dispositifs de stockage sont utilisés, la latence d'accès aux données n'est pas entièrement satisfaisante. En vue de la mise en œuvre d'applications réseaux à grande échelle, il est nécessaire de réduire davantage la latence d'accès aux données et d'augmenter le débit des requêtes traitées.
Exposé de l'invention
[0007] La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l'art antérieur, notamment ceux exposés précédemment.
[0008] À cet effet, selon un aspect de l'invention, il est proposé un procédé de traitement de requêtes d'accès à des données, le procédé étant mis en œuvre par une entité connectée à un réseau, ladite entité comprenant une carte réseau et un noyau de système d'exploitation. Le procédé comprend des étapes de : • interception par la carte réseau d'un paquet réseau à destination d'une application configurée pour traiter et répondre auxdites requêtes d'accès, ledit paquet réseau portant une requête de lecture comprenant un identifiant d'une donnée ;
• transmission par la carte réseau de la requête de lecture au noyau en fonction de la présence d'une donnée correspondant audit identifiant dans une première mémoire cache de la carte réseau ; et
• émission par la carte réseau d'une réponse à la requête de lecture, ladite réponse étant déterminée en fonction de la présence d'une donnée correspondant audit identifiant dans la première mémoire cache ou dans une deuxième mémoire cache du noyau.
[0009] Par « requêtes d'accès à des données », il est fait référence ici à des requêtes d'accès en écriture ou en lecture de données informatiques. Typiquement, les requêtes peuvent être émises par des dispositifs clients et transmises par l'intermédiaire d'un réseau de communication.
[0010] Par « mémoire cache », il est fait référence ici à une mémoire qui enregistre des copies de données d'une application en vue de diminuer le temps d'accès à ces données.
[0011] Par « noyau », il est fait référence ici à un noyau de système d'exploitation (ou « kernel » en anglais) et ainsi à un programme d'ordinateur permettant de gérer les ressources d'un ordinateur et permettant aux différents composants, matériels et logiciels, de communiquer entre eux. Dans le contexte de la présente invention, les étapes mises en œuvre par le noyau sont réalisées dans l'espace noyau. Par exemple, les étapes mises en œuvre par le noyau sont réalisées par les pilotes informatiques (ou « in-kernel drivers » en anglais) de la carte réseau, les pilotes informatiques étant installés dans le noyau.
[0012] Par « application », il est fait référence ici à un programme d'ordinateur mis en œuvre dans l'espace utilisateur, reposant ainsi sur les mécanismes d'abstraction fournis par le noyau. Dans le contexte de la présente invention, et de manière différente des étapes mises en œuvre par le noyau, des étapes mises en œuvre par l'application sont réalisées dans l'espace utilisateur. À titre d'exemple, l'application peut être une application de stockage de données en réseau.
[0013] Selon le procédé proposé, l'étape de transmission d'une requête de lecture au noyau est réalisée en fonction de la présence d'une donnée correspondant à l'identifiant dans la première mémoire cache. À titre d'exemple, si la carte réseau comprend la donnée demandée, la carte réseau traite la requête et ne la transmet donc pas au noyau. Selon un autre exemple, si la première mémoire cache ne comprend pas la donnée demandée, la carte réseau transmet la requête au noyau. [0014] De plus, selon le procédé proposé, la réponse à une requête de lecture est déterminée en fonction de la présence d'une donnée correspondant à l'identifiant dans les mémoires caches. Par exemple, si une des mémoires caches comprend la donnée demandée, la réponse émise comprend la donnée lue dans cette mémoire cache. Selon un autre exemple, si l'identifiant ne correspond à aucune donnée de l'application, la réponse émise peut être un message d'erreur.
[0015] L'invention proposée consiste en une architecture hiérarchique de mémoires caches sur plusieurs niveaux d'un système informatique. Cette architecture multi-caches, comprenant un premier niveau de cache mis en œuvre par la carte réseau et un deuxième niveau de cache mis en œuvre par le noyau, vise notamment à accélérer la latence liée aux accès réseaux de lecture de données d'une application. Ainsi, les requêtes sont traitées au plus bas niveau possible, soit par la carte réseau, soit par le noyau. Si une requête de lecture de donnée ne peut être traitée par le premier niveau de cache mis en œuvre par la carte réseau, la requête est transmise au deuxième niveau de cache mis en œuvre par le noyau.
[0016] Les premier et deuxième niveaux de cache permettent d'accélérer le traitement des requêtes d'accès à des données. La carte réseau est configurée pour traiter et répondre à une requête reçue dans un paquet réseau et comprend le premier niveau de cache. Le traitement d'une requête par la carte réseau permet d'éviter son transfert au noyau et ainsi de réduire la latence de traitement. Le traitement d'une requête par la carte réseau permet en outre d'économiser des ressources de traitement puisque le traitement du paquet réseau par le noyau n'est pas nécessaire. Le noyau est configuré pour traiter et répondre à une requête et comprend le deuxième niveau de cache. Par exemple, le noyau est configuré pour traiter les requêtes en interceptant les paquets réseaux au niveau des pilotes informatiques de la carte réseau. Par exemple, les pilotes informatiques comprennent un point d'attache (connu sous le nom de « hook » en anglais) permettant de programmer un traitement particulier sur les paquets réseaux reçus, ce qui permet de modifier le traitement par défaut des paquets réseaux réalisé par le noyau. Le traitement d'une requête par le noyau permet d'éviter son transfert à l'application et par conséquent de réduire la latence de traitement et d'économiser des ressources de traitement puisque la requête n'est pas traitée par l'application
[0017] En traitant les requêtes de lecture au niveau de la carte réseau ou au niveau du noyau, le procédé proposé permet entre autres de réduire la latence d'accès aux données, d'augmenter le nombre et le débit des requêtes traitées et de minimiser l'utilisation des ressources de traitement. Le procédé proposé permet ainsi de pallier les risques de congestion. En outre, le procédé proposé permet une utilisation efficace des ressources matérielles et logicielles de l'entité et le partage de celles-ci avec d'autres applications.
[0018] En outre, la mise en œuvre du premier niveau de cache au niveau de la carte réseau et du deuxième niveau de cache au niveau de l'espace noyau est transparente pour l'application qui s'exécute dans l'espace utilisateur. Ainsi, mettre en œuvre et exploiter les premier et deuxième niveaux de cache ne nécessitent aucunement de modifier l'application.
[0019] Selon un mode de réalisation particulier, la transmission de la requête par la carte réseau au noyau est réalisée si la première mémoire cache ne comprend pas une donnée correspondant à l'identifiant compris dans la requête de lecture. De plus, si la première mémoire cache comprend une donnée correspondant à l'identifiant, alors la réponse à la requête comprend ladite donnée lue dans la première mémoire cache ; ou, si la deuxième mémoire cache comprend une donnée correspondant à l'identifiant compris dans la requête de lecture, ladite réponse comprend ladite donnée lue dans la deuxième mémoire cache.
[0020] Ce mode de réalisation permet d'assurer la fiabilité des réponses aux requêtes de lecture émises par l'entité. En effet, selon ce mode de réalisation, une requête de lecture n'est traitée par la carte réseau que si la première mémoire cache comprend une donnée correspondant à l'identifiant compris dans la requête.
[0021] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend, si aucune desdites mémoires caches ne comprend une donnée correspondant audit identifiant, une étape de transmission de la requête de lecture à l'application, la réponse émise par la carte réseau comprenant une donnée correspondant audit identifiant, cette donnée étant émise par l'application en réponse à la requête de lecture.
[0022] Ce mode de réalisation permet de garantir un traitement certain des requêtes de lecture. Si un niveau de cache ne comprend pas la donnée demandée, celui-ci transmettra nécessairement la requête au niveau supérieur ; et si aucun des premier et deuxième niveaux de cache ne sont en mesure de traiter la requête de lecture, alors celle-ci est traitée par l'application. Les étapes mises en œuvre par l'application sont réalisées au niveau de l'espace utilisateur, tandis que les étapes mises en œuvre par le noyau sont réalisées au niveau de l'espace noyau.
[0023] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend un mécanisme d'exception permettant à un niveau de cache de transmettre une requête au niveau supérieur, si ce niveau de cache n'est pas en mesure de traiter la requête. De manière préférentielle, une requête de lecture n'est transmise par un niveau de cache à un niveau supérieur que si la mémoire de ce niveau de cache ne comprend pas la donnée demandée.
[0024] Selon un mode de réalisation, l'application est configurée pour gérer des accès concurrents. Par exemple, l'application est en mesure de traiter plusieurs requêtes d'écriture émises par des dispositifs clients différents et portant sur une même donnée, et une requête de lecture portant sur cette donnée. Ainsi, suite à une ou plusieurs requêtes d'écriture, une donnée enregistrée dans une des mémoires caches peut ne plus être identique à la donnée de l'application correspondant au même identifiant. Il est alors nécessaire de tenir compte de la validité des données enregistrées dans les mémoires caches pour traiter des requêtes et répondre à celles-ci.
[0025] Pour ce faire, selon un mode de réalisation particulier, la requête de lecture est transmise par la carte réseau au noyau si la première mémoire cache ne comprend pas une donnée valide correspondant audit identifiant ; et la requête de lecture est transmise par le noyau à l'application si aucune desdites mémoires caches ne comprend une donnée valide correspondant audit identifiant. En outre, selon ce mode de réalisation, ladite réponse émise par la carte réseau comprend une donnée valide correspondant audit identifiant.
[0026] Par « donnée valide », il est fait référence ici, pour un certain identifiant, à une donnée qui peut être utilisée pour répondre à une requête de lecture comprenant cet identifiant. Pour un certain identifiant, une donnée valide est nécessairement identique à la donnée de l'application associée au même identifiant. Et par « donnée invalide », il est fait référence ici, pour un certain identifiant, à une donnée qui ne peut pas être utilisée pour répondre à une requête de lecture comprenant cet identifiant. Pour un certain identifiant, une donnée invalide n'est pas nécessairement identique à la donnée de l'application associée au même identifiant.
[0027] Ce mode de réalisation permet de prendre en compte la validité des données enregistrées dans les mémoires caches pour traiter des requêtes et répondre à celles-ci. Ainsi, ce mode de réalisation permet de mettre en œuvre un traitement des requêtes par les différents niveaux de cache en fonction de la cohérence des données enregistrées dans les mémoires caches avec les données de l'application. Par ailleurs, ce mode de réalisation, en prenant en compte la validité des données, peut en outre être avantageux pour mettre en œuvre un mécanisme d'expiration de données.
[0028] Dans le contexte de l'invention, la réponse à une requête de lecture comprend ladite donnée valide correspondant à l'identifiant compris dans la requête. En effet, si l'application comprend une donnée correspondant à l'identifiant compris dans la requête de lecture reçue, la réponse à une requête de lecture comprend la donnée demandée.
[0029] Ce mode de réalisation permet d'assurer la fiabilité des réponses aux requêtes de lecture émises par l'entité. Si l'application comprend une donnée correspondant à l'identifiant de la requête de lecture, alors la donnée correspondant à l'identifiant est transmise par l'entité dans la réponse à la requête. Ainsi, pour les dispositifs clients émetteurs de requêtes, l'accès aux données de l'application présente, en plus d'une latence réduite, une fiabilité de traitement des requêtes par l'entité.
[0030] Selon un mode de réalisation particulier, les requêtes d'accès à des données et/ou les réponses aux requêtes sont transmises par l'intermédiaire d'un réseau informatique mettant en œuvre un protocole réseau IP (acronyme de l'expression anglo-saxonne « Internet Protocol »). [0031] L'utilisation du protocole IP permet d'acheminer des paquets de données entre un dispositif client et l'entité de traitement de requêtes. En outre, le protocole IP permet d'acheminer de manière efficace les paquets dans un réseau informatique mettant en œuvre un mécanisme de transmission « au mieux » (ou plus couramment désigné par l'expression anglo-saxonne « best-effort delivery »).
[0032] Selon un mode de réalisation particulier, les requêtes de lecture et/ou les réponses aux requêtes de lecture sont transmises par l'intermédiaire d'un réseau informatique mettant en œuvre un protocole de transport UDP (acronyme de l'expression anglo-saxonne « User Datagram Protocol »).
[0033] L'utilisation du protocole UDP permet de transmettre les requêtes de lecture et/ou leurs réponses de manière simple et rapide entre un dispositif client et l'entité de traitement de requêtes. La transmission de données avec le protocole UDP ne requiert aucune communication préalable pour établir la connexion entre un dispositif client et l'entité de traitement de requêtes et ne met pas en œuvre de retransmissions, ce qui permet réduire la latence d'accès aux données.
[0034] Selon un mode de réalisation particulier, les paquets réseaux interceptées par la carte réseau sont les paquets réseaux dont le port de destination correspond au port de l'application.
[0035] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend en outre une étape de :
• enregistrement dans au moins une des mémoires caches de la donnée reçue de l'application en réponse à la requête de lecture, l'enregistrement étant réalisé en fonction dudit identifiant.
[0036] Ce mode de réalisation permet d'enregistrer dans les mémoires caches des données. Le noyau utilise un mécanisme d'interception des données émises en réponse à des requêtes de lecture pour potentiellement les enregistrer dans les mémoires caches en fonction de leurs identifiants. En d'autres termes, le noyau enregistre ou non une donnée interceptée en fonction de son identifiant. Par exemple, le noyau peut enregistrer une donnée dans une mémoire cache, si cette donnée est fréquemment demandée. Ce mode de réalisation permet en particulier d'assurer la cohérence entre les données des mémoires caches et les données de l'application. De plus, le mécanisme d'interception permet d'enregistrer des données sans nécessiter de traitements et d'échanges de données supplémentaires entre les différents niveaux de cache et l'application. L'enregistrement d'une donnée dans la première mémoire de cache est effectué par le noyau, ce qui permet de libérer des ressources de traitement au niveau de la carte réseau. [0037] Selon un mode de réalisation particulier, l'enregistrement dans une des mémoires caches, de la donnée comprise dans la réponse à une requête de lecture, est réalisé si la mémoire cache comprend une donnée invalide ou aucune donnée correspondant à l'identifiant compris dans la requête de lecture.
[0038] Un avantage de ce mode de réalisation est de permettre l'enregistrement d'une donnée dans la mémoire cache ou la mise à jour de la donnée enregistrée dans une mémoire cache. Ainsi, si une des mémoires caches comprend une donnée correspondant à l'identifiant de la requête de lecture et que cette donnée est invalide, alors la donnée émise en réponse à la requête est utilisée pour mettre à jour la donnée dans la mémoire cache. En particulier, la mise à jour de la donnée correspondant à l'identifiant compris dans la requête de lecture est réalisée en interceptant la donnée émise en réponse à la requête de lecture. Ce mécanisme d'interception permet de mettre à jour une donnée dans une mémoire cache sans nécessiter de traitements et d'échanges de données supplémentaires entre les différents niveaux de cache et l'application.
[0039] Les mémoires caches des premier et deuxième niveaux de cache sont de tailles limitées. Il est donc essentiel d'enregistrer dans les mémoires caches les données de l'application fréquemment demandées, ce qui permet d'augmenter le nombre de requêtes traitées par la carte réseau ou le noyau et ainsi de réduire efficacement la latence d'accès aux données. Pour stocker une donnée dans une mémoire cache, l'entrée mémoire à utiliser est déterminée sur la base de l'identifiant de la donnée à stocker. Toutefois, des identifiants différents peuvent être associés à une seule et même entrée mémoire. Alors, plusieurs données sont en concurrence pour être enregistrées dans cette même entrée mémoire. En considérant une entrée mémoire pour laquelle plusieurs données sont en concurrence, enregistrer dans l'entrée mémoire la donnée la plus fréquemment demandée permet de réduire la latence d'accès aux données.
[0040] Selon un mode de réalisation particulier, l'enregistrement dans une des mémoires caches, de la donnée émise par l'application en réponse à une requête de lecture, est réalisé en fonction d'une comparaison entre l'identifiant compris dans la requête de lecture et un identifiant d'une donnée enregistrée dans la mémoire cache. En particulier, l'identifiant compris dans la requête de lecture et l'identifiant de la donnée enregistrée sont associés à une seule et même entrée de la mémoire cache. La donnée comprise dans la réponse et la donnée enregistrée sont ainsi des données en concurrence pour une même entrée mémoire.
[0041] Selon un mode de réalisation particulier, pouvant être combiné ou non avec le mode de réalisation précédent, l'enregistrement dans une des mémoires caches, de la donnée comprise dans la réponse à une requête de lecture, est réalisé en fonction d'une comparaison entre un seuil et un compteur associé à une donnée enregistrée dans la mémoire cache. En particulier, la donnée comprise dans la réponse et la donnée enregistrée sont des données concurrentes pour une même entrée mémoire.
[0042] Un avantage de ces modes de réalisation est de maintenir dans la première mémoire cache et la deuxième mémoire cache les données fréquemment demandées tout en évitant que celles-ci ne soient remplacées par des données moins fréquemment accédées. En outre, ce mode de réalisation permet de minimiser la complexité des traitements pour sélectionner les données à enregistrer dans les différents niveaux de cache et de ne pas augmenter la latence d'accès aux données de l'application.
[0043] Selon un mode de réalisation particulier, les données enregistrées dans une mémoire cache sont les données demandées par le plus grand nombre de requêtes de lecture sur une période déterminée.
[0044] Le fait d'enregistrer dans les mémoires caches les données les plus fréquemment requêtées permet de traiter un nombre plus important de requêtes par le premier et le deuxième niveau de cache et ainsi de réduire davantage la latence d'accès aux données.
[0045] Selon un mode de réalisation particulier, au moins une des mémoires caches comprend une table de hachage, et le procédé de traitement de requêtes comprend une étape de :
• détermination d'un haché sur la base de l'identifiant compris dans la requête de lecture pour indexer la donnée correspondant à l'identifiant dans la table de hachage.
[0046] Le fait d'utiliser une table de hachage pour enregistrer les données dans une mémoire cache permet une association directe entre un identifiant et une donnée. Une telle table de hachage permet ainsi de retrouver une donnée rapidement, en la cherchant à un emplacement de la table correspondant au résultat d’une fonction de hachage. En particulier, une telle structure de données offre une complexité en temps constant pour les opérations de recherche, d'insertion ou d'invalidation d'une donnée. Ainsi, ce mode de réalisation permet de réduire la latence due aux traitements des requêtes et permet à l'entité de traiter une charge importante avec un débit de requêtes élevé.
[0047] Selon un mode de réalisation particulier, le haché pour indexer une donnée dans la table de hachage est déterminé sur la base de l'identifiant de la donnée et d'une fonction de hachage Fowler-Noll-Vo-1A, plus couramment désignée par l'acronyme FNV-1A.
[0048] Un avantage de ce mode de réalisation particulier est que la fonction de hachage FNV-1A permet notamment de déterminer le haché d'un identifiant tout en lisant l'identifiant dans la requête, permettant ainsi de réduire la latence due au traitement des requêtes et plus généralement de gagner en performance par rapport à un calcul de haché réalisé a posteriori. [0049] Selon un mode de réalisation particulier, la mémoire cache de la carte réseau et la mémoire cache du noyau sont de tailles différentes. Plus particulièrement, la taille de la mémoire cache de la carte réseau est inférieure à la taille de la mémoire cache du noyau.
[0050] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend des étapes de :
• réception par la carte réseau d'une requête d'écriture comprenant un identifiant d'une donnée à écrire, et éventuellement la donnée à écrire ;
• transmission par la carte réseau de la requête d'écriture au noyau ; et
• transmission par le noyau de la requête d'écriture à l'application, l'application étant configurée pour traiter et répondre aux requêtes d'accès.
[0051] Un avantage de ces modes de réalisation particuliers est de garantir le traitement des requêtes d'écriture par l'application, permettant ainsi de garantir que les données de l'application restent à jour. L'application est configurée pour traiter des accès en écriture et en lecture concurrents. À titre d'exemple, l'application est configurée pour traiter deux requêtes d'écriture portant sur une même donnée et émises par des dispositifs clients différents, puis une requête de lecture portant sur cette donnée. Ainsi, ce mode de réalisation permet de contribuer à la gestion des accès concurrents.
[0052] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend en outre une étape de :
• transmission d'une réponse à la requête d'écriture, la réponse comprenant un accusé de réception.
[0053] Ce mode de réalisation particulier permet d'accuser réception de la requête d'écriture au dispositif client émetteur de la requête, et ainsi de signaler au dispositif client le traitement de la requête d'écriture.
[0054] Selon un mode de réalisation particulier, les requêtes d'écriture et/ou les réponses aux requêtes d'écriture sont transmises par l'intermédiaire d'un réseau informatique mettant en œuvre un protocole de transport TCP (acronyme de l'expression anglo-saxonne « Transmission Control Protocol »).
[0055] Ce mode de réalisation particulier permet de mettre en œuvre des échanges de données fiables entre un dispositif client et une entité de traitement de requêtes dans le réseau informatique, et ainsi de garantir la livraison des requêtes d'écriture et/ou des réponses aux requêtes d'écritures.
[0056] Suite à la réception d'une requête d'écriture comprenant l'identifiant d'une donnée à écrire, l'application traite la requête d'écriture. Le traitement de la requête d'écriture par l'application peut entrainer ou non une modification de la donnée de l'application associée à cet identifiant. Si une mémoire cache comprend une donnée associée à cet identifiant, alors la donnée enregistrée peut : soit correspondre à une version antérieure et obsolète de la donnée de l'application ; soit être identique à la donnée de l'application. Ainsi, la donnée enregistrée dans la mémoire cache n'est pas nécessairement identique à la donnée de l'application. Il est alors nécessaire d'invalider la donnée enregistrée dans la mémoire cache pour que celle-ci ne soit pas utilisée pour répondre à une requête de lecture.
[0057] Pour ce faire, selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend une étape de :
• si une des mémoires caches comprend une donnée correspondant à l'identifiant compris dans une requête d'écriture, invalidation dans la mémoire cache de la donnée correspondant à l'identifiant compris dans la requête d'écriture.
[0058] Ce mode de réalisation particulier permet de contribuer à garantir la cohérence des données de la première et de la deuxième mémoires caches avec les données de l'application. En outre, le fait d'invalider suite à une requête d'écriture les données correspondantes dans les différents niveaux de cache permet de s'assurer de ne pas transmettre une donnée obsolète en réponse à une requête de lecture. Ainsi, les requêtes d'écriture, avant d'être délivrées à l'application, sont utilisées par la carte réseau et le noyau pour invalider les entrées des différents niveaux de cache.
[0059] L'invalidation dans une mémoire cache d'une donnée peut être réalisée en mettant à une valeur nulle un indicateur de validité associé à la donnée. À l'inverse, une donnée valide peut être associée à un indicateur de validité de valeur non-nulle.
[0060] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend une étape de :
• enregistrement d'un premier programme d'ordinateur dans la carte réseau, le premier programme d'ordinateur comportant des instructions pour la mise en œuvre des étapes réalisées par la carte réseau d'un procédé de traitement de requêtes tel que décrit-ci dessus, lorsque le premier programme d'ordinateur est exécuté par un premier processeur.
[0061] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend une étape de : enregistrement d'un deuxième programme d'ordinateur dans le noyau, le deuxième programme d'ordinateur comportant des instructions pour la mise en œuvre des étapes réalisées par le noyau d'un procédé de traitement de requêtes tel que décrit- ci dessus, lorsque le deuxième programme d'ordinateur est exécuté par un deuxième processeur.
[0062] Selon un aspect de l'invention, il est proposé une entité de traitement de requêtes d'accès à des données, l'entité étant connectée à un réseau, l'entité comprenant une carte réseau et un noyau de système d'exploitation, la carte réseau comprenant une première mémoire cache, le noyau comprenant une deuxième mémoire cache, ladite entité comprenant :
• un module de réception réseau compris dans la carte réseau pour intercepter un paquet réseau à destination d'une application configurée pour traiter et répondre auxdites requêtes d'accès, ledit paquet réseau portant une requête de lecture comprenant un identifiant d'une donnée ;
• un premier module de détermination compris dans la carte réseau pour déterminer la présence dans la première mémoire cache d'une donnée correspondant audit identifiant ;
• un premier module de transmission compris dans la carte réseau pour transmettre la requête de lecture au noyau ;
• un deuxième module de détermination compris dans le noyau pour déterminer la présence dans la deuxième mémoire cache d'une donnée correspondant audit identifiant ; et
• un module d'émission réseau compris dans la carte réseau pour émettre une réponse à la requête de lecture.
[0063] Selon un mode de réalisation, ladite entité comprend :
• un premier module de lecture compris dans la carte réseau pour lire la donnée dans la première mémoire cache ; et
• un deuxième module de lecture compris dans le noyau pour lire la donnée dans la deuxième mémoire cache.
[0064] Selon un mode de réalisation, le premier module de détermination compris dans la carte réseau est configuré pour déterminer la présence et la validité d'une donnée correspondant à un identifiant dans la première mémoire cache. En outre, le deuxième module de détermination compris dans le noyau est configuré pour déterminer la présence et la validité d'une donnée correspondant à un identifiant dans la deuxième mémoire cache.
[0065] Selon un mode de réalisation particulier, l'entité comprend en outre une application, l'application comprenant une mémoire d'application pour enregistrer les données de l'application, l'entité comprenant en outre : • un deuxième module de transmission compris dans le noyau pour transmettre la requête à l'application ;
• un module de traitement et de réponse compris dans l'application pour traiter et répondre aux requêtes d'accès à des données ;
• un deuxième module de réception compris dans le noyau pour intercepter la donnée valide émise par l'application en réponse à la requête ; et
• un premier module de réception compris dans la carte réseau pour recevoir en provenance de l'application une réponse à la requête de lecture.
[0066] Selon un mode de réalisation particulier, l'entité de traitement de requêtes est un serveur DNS (acronyme de l'expression anglo-saxonne « Domain Name System »), les données de l'application étant par exemple des adresses IP et les identifiants étant des URLs (acronyme de l'expression anglo-saxonne « Uniform Resource Locator »).
[0067] Selon un mode de réalisation particulier, ladite entité est un serveur de clés, comprenant par exemple des paires clé-valeur.
[0068] Selon un autre aspect de l'invention, il est proposé un dispositif client connecté à un réseau, le dispositif client comprenant :
• un module d'émission pour transmettre des requêtes d'accès à des données ; et
• un module de réception pour recevoir des réponses auxdites requêtes.
[0069] Selon un aspect de l'invention, il est proposé un programme d'ordinateur comprenant instructions pour la mise en œuvre des étapes du procédé de traitement de requêtes tel que décrit ci-dessus lorsque les instructions sont exécutées par un ou plusieurs processeurs.
[0070] Le programme d'ordinateur peut être formé d'une ou plusieurs sous-parties stockées dans une même mémoire ou dans des mémoires distinctes. Le programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0071] Selon un mode de réalisation particulier, le programme d'ordinateur comprend des instructions de code eBPF (acronyme de l'expression anglo-saxonne « extended Berkeley Packet Filter »).
[0072] Ce mode de réalisation particulier permet d'utiliser la technologie eBPF pour développer les différents niveaux de cache. La technologie eBPF permet notamment d'exécuter des instructions de codes dans l'espace noyau lors de l'exécution de pilotes informatiques, par exemple en exploitant un point d'attache des pilotes informatiques tel que décrit ci-dessus. [0073] Selon un aspect de l'invention, il est proposé un support d'informations lisible par ordinateur comprenant un programme d'ordinateur tel que décrit ci-dessus.
[0074] Le support d'informations peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une mémoire non-volatile ou ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une disquette ou un disque dur. D’autre part, le support de stockage peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par un réseau de télécommunication ou par un réseau informatique ou par d’autres moyens. Le programme selon l’invention peut être en particulier téléchargé sur un réseau informatique. Alternativement, le support d’informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé en question.
Brève description des dessins
[0075] D'autres caractéristiques et avantages de la présente invention ressortiront de la description fournie ci-après de modes de réalisation particuliers. Les modes de réalisation sont donnés à titre d'exemple illustratif et sont dépourvus de tout caractère limitatif. La description fournie ci-après est illustrée par les dessins ci- joints :
[Fig IA] la figure IA représente schématiquement des exemples de requêtes d'accès à des données entre des dispositifs clients et une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig IB] la figure IB représente schématiquement des exemples de requêtes d'accès à des données entre un dispositif client et une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig IC] la figure IC représente schématiquement des exemples de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 2A] la figure 2A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 2B] la figure 2B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 3A] la figure 3A représente schématiquement un exemple d'architecture fonctionnelle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ; [Fig 3B] la figure 3B représente schématiquement un exemple d'architecture logicielle et matérielle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 4] la figure 4 représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 5A] la figure 5A représente schématiquement un exemple d'architecture fonctionnel d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 5B] la figure 5B représente schématiquement un exemple d'architecture logicielle et matérielle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 6A] la figure 6A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 6B] la figure 6B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 6C] la figure 6C représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 7A] la figure 7A représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 7B] la figure 7B représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 7C] la figure 7C représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 8A] la figure 8A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 8B] la figure 8B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 8C] la figure 8C représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ;
[Fig 9] la figure 9 représente schématiquement des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier ; Description des modes de réalisation
[0076] La présente invention concerne un procédé de traitement de requêtes d'accès à des données, une entité, un programme d'ordinateur, et un support d'informations associés.
[0077] La figure IA représente schématiquement des exemples de requêtes d'accès à des données entre des dispositifs clients et une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0078] Tel qu'illustré par la figure IA, les dispositifs clients CLT sont connectés par l'intermédiaire d'un réseau informatique de communication NET à une entité SERV de traitement de requêtes d'accès à des données. L'entité SERV comprend des données d'une application. À titre d'exemple, l'entité SERV peut être un serveur de stockage de données en réseau. L'entité SERV peut également mettre en œuvre un serveur DNS de résolution de noms de domaine comprenant des URLs et des adresses IP. L'entité SERV peut mettre en œuvre un serveur de clés comprenant des paires clé-valeur. Selon un mode de réalisation particulier, l'application APP est une application de stockage de paires clé-valeur et peut par exemple être l'application Memcached, une application bien connue de l'homme du métier et couramment déployée. Les dispositifs clients CLT peuvent être des équipements utilisateurs, des terminaux mobiles, des objets communicants, des serveurs d'application, ou tout autre dispositif émetteur de requêtes d'accès à des données. Les requêtes d'accès à des données émises par les dispositifs clients CLT sont des demandes d'accès en écriture SET d'une donnée dans l'entité SERV, ou des demandes d'accès en lecture GET d'une donnée dans l'entité SERV. L'entité SERV de traitement de requêtes reçoit en provenance des dispositifs clients CLT des demandes d'accès en écriture ou en lecture de données GET, SET et traite ces demandes. De plus, l'entité SERV peut émettre à destination des dispositifs clients CLT des réponses REPJ3ET aux requêtes d'accès à des données GET, SET.
[0079] Dans le mode de réalisation particulier décrit ici, le réseau informatique de communication peut être de type Internet mettant par exemple en œuvre le protocole de transport IP, les moyens de communication des dispositifs clients CLT et de l'entité SERV s'appuyant notamment sur une interface de communication apte aux échanges de données. Aucune limitation n'est attachée à la nature de l'interface de communication entre les dispositifs clients CLT et l'entité SERV, qui peut être filaire ou non filaire, et peut mettre en œuvre tout protocole connu de l’homme du métier (Ethernet, Wi-Fi, Bluetooth, 3G, 4G, 5G, 6G, etc.). En outre, le réseau informatique ne se limite pas à un réseau Internet, tout autre réseau (propriétaire, etc.) pouvant être envisagé, de sorte que l'entité SERV de traitement de requêtes puisse être accessible par l'intermédiaire du réseau NET. [0080] La figure IB représente schématiquement des exemples de requêtes d'accès à des données entre un dispositif client et une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0081] Comme le montre la figure IB, les requêtes GET_A, SET_B d'accès à des données sont émises par un dispositif client CLT à destination de l'entité SERV de traitement de requêtes. Les requêtes d'accès à des données peuvent être des requêtes d'accès en lecture GET_A de données, et également être des requêtes d'accès en écriture SET_B de données. Une requête de lecture GET_A émise par un dispositif client CLT à destination de l'entité SERV comprend un identifiant ID_A d'une donnée D_A. À titre d'exemple, un identifiant peut être une URL et une donnée peut être une adresse IP. Suite au traitement de la requête de lecture GET_A, et en réponse à celle-ci, l'entité SERV émet une réponse REP_GET_A. La réponse REP_GET_A peut comprendre la donnée D_A demandée par le dispositif client CLT ou peut comprendre un message d'erreur ERR. Un message d'erreur ERR peut être transmis lorsque l'entité SERV ne comprend pas la donnée demandée, ou n'est pas en mesure de traiter une requête, par exemple suite à un dysfonctionnement, un état de congestion, etc. Une requête d'écriture SET_B émise par un dispositif client CLT à destination de l'entité SERV comprend un identifiant ID_B d'une donnée à écrire D_B, et éventuellement la donnée à écrire D_B. L'identifiant ID_B peut être identique ou différent de l'identifiant ID_A. Suite au traitement de la requête d'écriture SET_B, l'entité SERV peut émettre ou non une réponse REP_SET_B à destination du dispositif client CLT. La réponse REP_SET_B peut par exemple comprendre un accusé de réception ACK.
[0082] Selon un mode de réalisation particulier, les requêtes d'accès en lecture de données GET_A et leurs réponses REP_GET_A sont transmises par l'intermédiaire du réseau informatique NET mettant en œuvre un protocole réseau IP et un protocole de transport de type UDP. Le protocole de transport UDP permet de transmettre des données de manière simple et rapide entre deux entités en mode non connecté.
[0083] Selon un mode de réalisation particulier, les requêtes d'accès en écriture de données SET_B et leurs réponses REP_SET_B sont transmises par l'intermédiaire du réseau informatique NET mettant en œuvre un protocole réseau IP et un protocole de transport de type TCP.
[0084] La figure IC représente schématiquement des exemples de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0085] Dans la suite de la présente description, les signes de référence suivants sont utilisés : le signe de référence D_A désigne une donnée correspondant à l'identifiant ID_A ; les signes de référence D_A1, D_A2, D_A3 désignent des données valides correspondant à l'identifiant ID_A et enregistrées respectivement dans une première mémoire cache Cl, une deuxième mémoire cache C2, et une mémoire C3 de l'application APP ; le signe de référence D_A1' désigne une donnée correspondant à l'identifiant ID_A et invalide dans la première mémoire cache Cl.
[0086] Tel qu'illustré par la figure IC, une donnée D_A1, D_A2, D_A3 de l'entité SERV est identifiée par un identifiant ID_A. L'entité SERV peut comprendre plusieurs mémoires Cl, C2, C3. En particulier, l'entité SERV peut comprendre : une carte réseau NIC comprenant une première mémoire cache Cl et un noyau de système d'exploitation KER comprenant une deuxième mémoire cache C2. Les données stockées dans la première mémoire cache Cl et dans la deuxième mémoire cache C2 sont des réplications de données de l'application APP. L'entité SERV peut en outre comprendre l'application APP, située dans une couche d'application de l'entité SERV et mise en œuvre dans l'espace utilisateur, l'application APP comprenant la mémoire d'application C3. L'application APP est configurée pour traiter et répondre à des requêtes d'accès GET_A, SET_B, et en particulier pour gérer des accès concurrents. Par exemple, l'application APP est en mesure de traiter plusieurs requêtes d'écriture SET_B émises par des dispositifs clients CLT différents et portant sur la même donnée D_B, et une requête de lecture GET_A portant sur cette donnée D_B.
[0087] Dans le mode de réalisation particulier décrit ici, l'entité SERV assure la cohérence entre les données des mémoires caches Cl, C2 et les données de l'application APP. Afin d'assurer la cohérence entre ces différentes mémoires Cl, C2, C3, l'entité SERV identifie les données D_A1, D_A2 comprises dans les mémoires caches Cl, C2 soit comme étant valides D_A1, D_A2, soit comme étant invalides D_A1', D_A2'. Pour un identifiant ID_A, une donnée valide D_A1, D_A2 est nécessairement identique à la donnée D_A3 de l'application APP et peut être utilisée pour répondre à une requête de lecture GET_A comprenant l'identifiant ID_A. Pour un identifiant ID_A, une donnée invalide D_A1', D_A2' n'est pas nécessairement identique à la donnée D_A3 de l'application APP et ne peut pas être utilisée pour répondre à une requête de lecture GET_A comprenant l'identifiant ID_A.
[0088] La figure 2A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0089] Dans le mode de réalisation particulier décrit ici, le procédé est mis en œuvre par l'entité SERV connectée au réseau NET. Tel qu'illustré par la figure 2A, le procédé comprend les étapes décrites ci-après.
[0090] Dans la suite de la présente description, les étapes réalisées par la carte réseau NIC sont différenciées des étapes réalisées par le noyau KER. La carte réseau NIC met en œuvre les étapes dont les signes de référence commencent par la lettre N, tandis que le noyau KER met en œuvre les étapes dont les signes de référence commencent par la lettre K. [0091] À l'étape N20, la carte réseau NIC intercepte un paquet réseau à destination de l'application APP, le paquet réseau portant une requête de lecture GET_A. La requête GET_A comprend un identifiant ID_A d'une donnée à lire D_A. En particulier, la carte réseau NIC filtre l'ensemble des paquets reçus en provenance du réseau en inspectant leur port de destination afin de traiter uniquement les requêtes destinées à l'application APP.
[0092] À l'étape N30, la carte réseau NIC détermine si la requête GET_A doit être transmise au noyau KER en fonction de la présence d'une donnée D_A1 correspondant à l'identifiant ID_A dans la première mémoire cache Cl de la carte réseau NIC. Si oui, le procédé se poursuit à l'étape N50, sinon à l'étape N130.
[0093] À l'étape N50, la carte réseau NIC transmet la requête de lecture GET_A au noyau KER.
[0094] À l'étape N130, la carte réseau NIC émet une réponse REP_GET_A à la requête de lecture GET_A. La réponse REP_GET_A émise est déterminée en fonction de la présence d'une donnée correspondant à l'identifiant ID_A dans la première mémoire cache Cl de la carte réseau NIC ou dans la deuxième mémoire cache C2 du noyau KER.
[0095] Selon un mode de réalisation, la carte réseau NIC détermine à l'étape N30 si la première mémoire cache Cl comprend une entrée mémoire pour l'identifiant ID_A. Si la première mémoire cache Cl ne comprend pas d'entrée mémoire pour l'identifiant ID_A, la carte réseau NIC transmet à l'étape N50 la requête GET_A au noyau KER.
[0096] Selon un mode de réalisation, combiné ou non avec le précédent, la carte réseau NIC détermine à l'étape N30 si la première mémoire cache Cl comprend une donnée D_A1 correspondant à l'identifiant ID_A. Si la première mémoire cache Cl comprend la donnée D_A1 demandée, il n'est pas nécessaire de transmettre la requête GET_A au noyau KER. La carte réseau NIC émet à l'étape N130 la réponse REP_GET_A comprenant la donnée D_A1 lue dans la première mémoire cache Cl. Et, si la première mémoire cache Cl ne comprend la donnée D_A1 demandée, la carte réseau NIC transmet à l'étape N50 la requête GET_A au noyau KER.
[0097] Selon un mode de réalisation, si la requête GET_A est transmise au noyau KER, le noyau KER traite la requête GET_A en fonction de la présence d'une donnée D_A2 correspondant à l'identifiant ID_A dans la deuxième mémoire cache C2. À titre d'exemple, le traitement de la requête GET_A par le noyau KER peut être analogue au traitement mis en œuvre par la carte réseau NIC décrit ci-dessus. Ainsi, dans ce mode de réalisation, la réponse REP_GET_A émise à l'étape N130 est déterminée en fonction de la présence de la donnée D_A2 demandée dans la deuxième mémoire cache C2
[0098] Ainsi, et tel que mentionné ci-dessus, l'étape de transmission N50 est réalisée en fonction de la présence d'une donnée D_A1 correspondant à l'identifiant ID_A dans la première mémoire cache Cl ; et la réponse REP_GET_A à la requête GET_A émise par l'entité SERV est déterminée en fonction de la présence d'une donnée D_A1, D_A2 correspondant à l'identifiant ID_A dans la première mémoire Cl ou dans la deuxième mémoire cache C2.
[0099] La figure 2B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. Tel qu'illustré par la figure 2B, le procédé comprend les étapes décrites ci-après.
[0100] À l'étape N10, la carte réseau NIC reçoit, sur son interface réseau et en provenance d'un dispositif client CLT connecté au réseau NET, un paquet réseau portant une requête de lecture GET_A, la requête GET_A comprenant un identifiant ID_A d'une donnée à lire D_A.
[0101] À l'étape N20, la carte réseau NIC intercepte le paquet réseau portant la requête de lecture GET_A.
[0102] À l'étape N30, la carte réseau NIC détermine si la première mémoire cache Cl comprend une donnée valide D_A1 correspondant à l'identifiant ID_A.
[0103] Si la première mémoire cache Cl comprend la donnée valide D_A1, à l'étape N40, la carte réseau NIC lit la donnée valide D_A1 dans la première mémoire cache Cl. Le traitement de la requête de lecture GET_A par la carte réseau NIC permet d'éviter un transfert de la requête au noyau KER. Le procédé se poursuit à l'étape N130.
[0104] Si la première mémoire cache Cl ne comprend pas de donnée valide correspondant à l'identifiant ID_A, à l'étape N50, la carte réseau NIC transmet la requête de lecture GET_A au noyau KER.
[0105] À l'étape K60, le noyau KER détermine si la deuxième mémoire cache C2 comprend une donnée valide D_A2 correspondant à l'identifiant ID_A.
[0106] Si la deuxième mémoire cache C2 comprend la donnée valide D_A2, à l'étape K70, le noyau KER lit la donnée valide D_A2 dans la deuxième mémoire cache C2. Le traitement de la requête de lecture GET_A par le noyau KER permet d'éviter un transfert de la requête à un niveau supérieur de la pile réseau.
[0107] À l'étape N130, la carte réseau NIC émet une réponse REP_GET_A à la requête de lecture GET_A. La réponse REP_GET_A peut être émise à destination du dispositif client CLT émetteur de la requête et comprendre la donnée valide D_A1, D_A2 correspondant à l'identifiant ID_A ou un message d'erreur ERR.
[0108] Selon un mode de réalisation particulier, suite à l'étape K 70, le noyau KER transmet à la carte réseau NIC la réponse REP_GET_A à la requête de lecture GET_A, cette réponse comprenant la donnée valide D_A2 correspondant à l'identifiant ID_A et lue dans la deuxième mémoire cache C2. [0109] Par ailleurs, le deuxième niveau de cache mis en œuvre par le noyau KER est particulièrement adapté aux architectures de type multi-cœurs le noyau KER pouvant exploiter les cartes réseaux multi-queues afin de traiter en parallèle plusieurs requêtes sur les différents cœurs.
[0110] La figure 3A représente schématiquement un exemple d'architecture fonctionnelle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0111] Comme le montre la figure 3A, l'entité SERV comprend une carte réseau NIC et un noyau de système d'exploitation KER. L'entité SERV est connectée au réseau informatique NET par l'intermédiaire de sa carte réseau NIC. Les requêtes d'accès GET_A, SET_B sont reçues par la carte réseau NIC en provenance du réseau NET ; et les réponses REP_GET_A, REP_SET_B sont émises par la carte réseau NIC à destination du réseau NET. La carte réseau NIC et le noyau KER comprennent les modules décrits ci-après.
[0112] Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
[0113] Tel qu'illustré par la figure 3A, la carte réseau NIC comprend les modules suivants : un module de réception réseau MOD_RX1 pour recevoir et intercepter une requête de lecture GET_A comprenant un identifiant ID_A d'une donnée D_A ; un premier module de détermination MOD_DET1 pour déterminer si la première mémoire cache Cl comprend une donnée valide D_A1 correspondant à l'identifiant ID_A ; un premier module de lecture MOD_RD1 pour lire la donnée valide D_A1 correspondant à l'identifiant ID_A dans la première mémoire cache Cl ; un premier module de transmission MOD_FWD1 pour transmettre la requête de lecture GET_A au noyau KER ; et un module d'émission réseau MOD_TX1 pour transmettre une réponse REP_GET_A à la requête de lecture GET_A. La carte réseau NIC comprend en outre un premier module de réception pour recevoir en provenance du noyau KER une donnée valide D_A2, D_A3.
[0114] Tel qu'illustré par la figure 3A, le noyau KER comprend les modules suivants : un deuxième module de détermination MOD_DET2 pour déterminer si la deuxième mémoire cache C2 comprend une donnée valide D_A2 correspondant à l'identifiant ID_A ; et un deuxième module de lecture MOD_RD2 compris dans le noyau KER pour lire ladite donnée valide D_A2 dans la deuxième mémoire cache C2. Le noyau KER comprend en outre un deuxième module d'émission pour transmettre une réponse REP_GET_A à une requête GET_A à la carte réseau NIC.
[0115] Selon un mode de réalisation particulier, la carte réseau NIC et le noyau KER sont connectés par l'intermédiaire d'un bus de communication mettant en œuvre le protocole PCIe (acronyme de l'expression anglo-saxonne « Peripheral Component Interconnect Express »).
[0116] La figure 3B représente schématiquement un exemple d'architecture logicielle et matérielle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0117] Tel qu'illustré sur la figure 3B, l'entité SERV comprend une carte réseau NIC et un noyau de système d'exploitation KER. La carte réseau NIC comprend notamment : une mémoire cache Cl ; une unité de traitement ou processeur PROC1 ; et une mémoire MEM1. Bien entendu, la carte réseau NIC comprend des interfaces et un module de communication pour d'une part échanger des données avec d'autres dispositifs par l'intermédiaire du réseau NET et d'autre part pour échanger des données avec le noyau KER. La carte réseau NIC constitue une interface physique entre l'entité SERV et le réseau NET. La carte réseau NIC permet de préparer, d'envoyer et de contrôler les données circulant sur le réseau NET.
[0118] Selon un mode de réalisation particulier, la carte réseau NIC est une carte réseau programmable. Ainsi, la carte réseau NIC dispose de l'architecture matérielle d'un ordinateur. La carte réseau NIC comporte, notamment, un processeur PROC1, une mémoire vive RAM1, une mémoire morte MEM1 et une mémoire non volatile ROM1.
[0119] La mémoire MEM1 de la carte réseau NIC constitue un support d'informations ou d'enregistrement conforme à la présente invention, lisible par ordinateur et par le processeur PROC1 et sur lequel est enregistré un programme d'ordinateur PROG1 conforme à l'invention. Le programme d'ordinateur PROG1 comporte des instructions pour la mise en œuvre des étapes réalisées par la carte réseau NIC d'un procédé de traitement de requêtes d'accès à des données, lorsque le programme d'ordinateur PROG1 est exécuté par le processeur PROC1. Le programme d'ordinateur PROG1 définit les modules fonctionnels représentés par la figure 3A de la carte réseau NIC, qui s'appuient ou commandent les éléments matériels de cette dernière.
[0120] Tel qu'illustré sur la figure 3B, le noyau KER comprend notamment une mémoire cache C2. L'entité SERV comprend une unité de traitement ou processeur PROC2 et une mémoire MEM2 associés au noyau KER. Bien entendu, le noyau KER comprend une interface et un module de communication pour échanger des données avec la carte réseau NIC. En outre, le noyau KER peut comprendre une interface pour échanger des données avec l'application APP. [0121] Selon un mode de réalisation particulier, l'entité SERV dispose de l'architecture matérielle d'un ordinateur. Le noyau KER peut ainsi être associé à, notamment, un processeur PROC2, une mémoire vive RAM2, une mémoire morte MEM2 et une mémoire non volatile ROM2.
[0122] La mémoire MEM2 associée au noyau KER constitue un support d'informations ou d'enregistrement conforme à l'invention, lisible par ordinateur et par le processeur PROC2 et sur lequel est enregistré un programme d'ordinateur PROG2 conforme à l'invention. Le programme d'ordinateur PROG2 comporte des instructions pour la mise en œuvre des étapes réalisées par le noyau KER d'un procédé de traitement de requêtes d'accès à des données selon l'invention, lorsque le programme d'ordinateur PROG2 est exécuté par le processeur PROC2. Le programme d'ordinateur PROG2 définit les modules fonctionnels représentés par la figure 3A du noyau KER, qui s'appuient ou commandent les éléments matériels de ce dernier.
[0123] La mémoire MEM2 associée au noyau KER peut en outre constituer un support d'informations ou d'enregistrement conforme à l'invention, lisible par ordinateur et sur lequel est enregistré un programme d'ordinateur PROG12 conforme à l'invention. Le programme d'ordinateur PROG12 comporte des premières instructions pour la mise en œuvre des étapes réalisées par la carte réseau NIC d'un procédé de traitement de requêtes d'accès à des données selon l'invention, lorsque les premières instructions sont exécutées par un premier processeur PROC1. Le programme d'ordinateur PROG12 comporte en outre des deuxièmes instructions pour la mise en œuvre des étapes réalisées par le noyau KER d'un procédé de traitement de requêtes d'accès à des données selon l'invention, lorsque les deuxièmes instructions sont exécutées par un deuxième processeur PROC2. Le programme d'ordinateur PROG12 comprend ainsi des instructions pour la mise en œuvre des étapes d'un procédé de traitement de requête selon l'invention, lorsque le programme d'ordinateur est exécuté par un ordinateur. Le programme PROG12 définit les modules fonctionnels représentés par la figure 3A de la carte réseau NIC et du noyau KER, qui s'appuient ou commandent les éléments matériels de ce dernier.
[0124] Typiquement, les programmes d'ordinateur selon l'invention peuvent comprendre des instructions de code eBPF, la technologie eBPF étant ainsi utilisée pour développer les différents niveaux de cache. La technologie eBPF permet notamment d'exécuter des instructions de codes dans l'espace noyau.
[0125] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend le chargement ou l'enregistrement du programme d'ordinateur PROG1 dans la carte réseau NIC. Par exemple, le programme d'ordinateur PROG1 peut être chargé dans la carte réseau NIC par l'entité SERV et exécuté par la carte réseau NIC pour mettre en œuvre un procédé de traitement de requêtes tel que proposé. [0126] Selon un mode de réalisation particulier, le procédé de traitement de requêtes comprend une étape de chargement ou d'enregistrement du programme d'ordinateur PROG2 dans le noyau KER. Par exemple, le programme d'ordinateur PROG2 peut être chargé dans le noyau KER par l'entité SERV et exécuté par le noyau KER pour mettre en œuvre un procédé de traitement de requêtes tel que proposé. Plus particulièrement, le programme d'ordinateur PROG2 peut être exécuté par les pilotes informatiques de la carte réseau NIC installés dans le noyau KER.
[0127] La figure 4 représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0128] En particulier, le procédé illustré par la figure 4 en comparaison du procédé illustré par la figure 2B comprend les étapes supplémentaires suivantes.
[0129] Si, suite à l'étape K60 mise en œuvre par le noyau KER, la deuxième mémoire cache C2 ne comprend pas de données valides D_A2 correspondant à l'identifiant ID_A, le noyau KER transmet à l'étape K80 la requête de lecture GET_A à l'application APP.
[0130] À l'étape K90, le noyau KER reçoit une réponse REP_GET_A à la requête GET_A en provenance de l'application APP, cette réponse comprenant une donnée D_A3 correspondant à l'identifiant ID_A, qui est dite valide par la suite. Le noyau KER intercepte ainsi la donnée valide D_A3 émise par l'application APP en réponse à la requête GET_A.
[0131] À l'étape N120, la carte réseau NIC reçoit la réponse REP_GET_A en provenance du noyau KER et transmet cette réponse à l'étape N130 décrite précédemment.
[0132] La figure 5A représente schématiquement un exemple d'architecture fonctionnelle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0133] Tel qu'illustré par la figure 5A, la carte réseau NIC comprend, en comparaison de l'architecture illustrée par la figure 3A, les modules supplémentaires suivants : un premier module de réception MOD_RCV1 pour recevoir en provenance du noyau KER une donnée valide D_A2, D_A3 correspondant à l'identifiant ID_A.
[0134] Tel qu'illustré par la figure 5A, le noyau KER comprend, en comparaison de l'architecture illustrée par la figure 3A, les modules supplémentaires suivants : un deuxième module de transmission MOD_FWD2 pour transmettre la requête GET_A à l'application APP ; et un deuxième module de réception MOD_RCV2 pour recevoir en provenance de l'application APP une réponse REP_GET_A et intercepter la donnée valide D_A3 correspondant à l'identifiant ID_A comprise dans cette réponse.
[0135] Tel qu'illustré par la figure 5A, l'application APP comprend : une mémoire d'application
C3 pour enregistrer les données de l'application APP ; et un module de traitement et de réponse PROC_REP pour traiter et répondre à des requêtes d'accès à des données GET_A, SET_B.
[0136] Bien entendu, aucune limitation n'est attachée au fait que l'application APP soit intégrée dans l'entité SERV elle-même. L'application APP peut également être déportée à distance et mise en œuvre par une autre entité, cette autre entité étant dotée des composants matériels et logiciels d'un ordinateur, notamment : un processeur, une mémoire vive, une mémoire morte et mémoire non-volatile. L'entité SERV est ainsi située sur un plan intermédiaire entre un dispositif client CLT et l'application APP.
[0137] La figure 5B représente schématiquement un exemple d'architecture logicielle et matérielle d'une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0138] Tel qu'illustré sur la figure 5B, l'entité SERV comprend une carte réseau NIC, un noyau KER, et une application APP. En particulier, l'architecture illustrée par la figure 5B comprend en comparaison de l'architecture illustrée par la figure 3B les composants matériels et logiciels supplémentaires suivants.
[0139] Tel qu'illustré sur la figure 5B, l'entité SERV comprend une application APP. L'application APP comprend une mémoire C3 permettant de stocker les données de l'application APP.
[0140] Dans le mode de réalisation particulier décrit ici, la mémoire MEM2 associée au noyau KER constitue un support d'informations ou d'enregistrement conforme à l'invention, lisible par ordinateur et par le processeur PROC2 et sur lequel est enregistré un programme d'ordinateur PROG3 conforme à l'invention. Le programme d'ordinateur PROG3 comporte des instructions pour la mise en œuvre des étapes réalisées par l'application APP d'un procédé de traitement de requêtes d'accès à des données selon l'invention, lorsque le programme d'ordinateur PROG3 est exécuté par le deuxième processeur PROC2. Le programme d'ordinateur PROG3 définit les modules fonctionnels représentés par la figure 5A de l'application APP, qui s'appuient ou commandent les éléments matériels de cette dernière.
[0141] La mémoire MEM2 associée au noyau KER peut en outre constituer un support d'informations ou d'enregistrement conforme à l'invention, lisible par ordinateur et sur lequel est enregistré un programme d'ordinateur PROG123 conforme à l'invention. Le programme d'ordinateur PROG123 comporte les instructions du programme d'ordinateur PROG12 et en outre les instructions du programme d'ordinateur PROG3. Le programme d'ordinateur PROG123 comprend ainsi des instructions pour la mise en œuvre des étapes d'un procédé de traitement de requête selon l'invention, lorsque le programme d'ordinateur est exécuté par un ordinateur. Le programme d'ordinateur PROG123 définit les modules fonctionnels représentés par la figure 5A de la carte réseau NIC, du noyau KER et de l'application APP, qui s'appuient ou commandent les éléments matériels de ce dernier. [0142] Typiquement, les données de l'application APP comprises dans la mémoire C3 sont stockées dans la mémoire vive RAM2 de l'entité SERV et accédées par l'application APP depuis l'espace utilisateur ; et les données du noyau KER comprises dans la deuxième mémoire cache C2 sont stockées dans mémoire vive RAM2 de l'entité SERV et accédées par le noyau KER depuis l'espace noyau.
[0143] La figure 6A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. En particulier, le procédé illustré par la figure 6A comprend en comparaison de la figure 4 les étapes supplémentaires décrites ci-après.
[0144] À l'étape K90, le noyau KER intercepte une réponse REP_GET_A à la requête de lecture GET_A, cette réponse comprenant une donnée valide D_A3. Le noyau KER peut utiliser la donnée valide D_A3 reçue pour enregistrer une nouvelle donnée dans la mémoire cache Cl, C2 ou bien remplacer une donnée enregistrée D_C1, D_C2 dans la mémoire cache Cl, C2.
[0145] À l'étape K100, le noyau KER peut enregistrer dans la deuxième mémoire cache C2 la donnée valide D_A3 reçue de l'application APP. Le noyau KER transmet à destination de la carte réseau NIC la réponse REP_GET_A à la GET_A.
[0146] À l'étape Kl 10, le noyau KER peut enregistrer dans la première mémoire cache Cl la donnée valide D_A3 reçue de l'application APP.
[0147] À l'étape N120, la carte réseau NIC reçoit en provenance du noyau KER la réponse REP_GET_A qui est émise à l'étape N130.
[0148] Dans un mode de réalisation particulier, le noyau KER peut également enregistrer dans la première mémoire cache Cl une donnée valide D_A2 émise en réponse à une requête GET_A. En effet, à l'étape K70, le noyau KER lit la donnée valide D_A2 dans la deuxième mémoire cache C2. Suite à cette étape, le noyau KER peut enregistrer la donnée valide D_A2 dans la première mémoire cache Cl avant de transmettre la réponse REP_GET_A à la requête GET_A à la carte réseau NIC.
[0149] La figure 6B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. En particulier, le procédé illustré par la figure 6B comprend en comparaison du procédé illustré par la figure 6A les étapes supplémentaires suivantes.
[0150] Suite à l'étape K90 d'interception, par le noyau KER d'une donnée D_A3 valide correspondant à l'identifiant ID_A, le noyau KER met en œuvre une étape K101.
[0151] À l'étape K101, le noyau KER détermine si la deuxième mémoire cache C2 comprend une donnée invalide D_A2' correspondant à l'identifiant ID_A. ZI
[0152] À l'étape K102, si la deuxième mémoire C2 comprend la donnée D_A2', le noyau KER enregistre dans la deuxième mémoire cache C2 la donnée valide D_A3 reçue de l'application APP et correspondant à l'identifiant ID_A.
[0153] À l'étape Kill, le noyau KER détermine si la première mémoire cache Cl comprend une donnée D_A1' correspondant à l'identifiant ID_A.
[0154] À l'étape K112, si la première mémoire Cl comprend la donnée D_A1', le noyau KER enregistre dans la première mémoire cache Cl la donnée valide D_A3 reçue de l'application APP et correspondant à l'identifiant ID_A.
[0155] La figure 6C représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. En particulier, le procédé illustré par la figure 6C comprend en comparaison du procédé illustré par la figure 6A les étapes supplémentaires suivantes.
[0156] Suite à l'étape K90 d'interception, par le noyau KER d'une donnée D_A3 valide correspondant à l'identifiant ID_A, le noyau KER met en œuvre au moins une des étapes K103 et K104.
[0157] À l'étape K103, le noyau KER compare l'identifiant ID_A à un identifiant ID_C d'une donnée enregistrée D_C2 dans la deuxième mémoire cache C2.
[0158] À l'étape K104, le noyau KER compare un seuil THR_2 à un compteur CNT_C2 associé à une donnée enregistrée D_C2 dans la deuxième mémoire cache C2 correspondant à un identifiant ID_C.
[0159] À l'étape K105, en fonction du résultat d'au moins une des comparaisons réalisées aux étapes Kl 03 et Kl 04, le noyau KER enregistre ou non la donnée valide D_A3 reçue de l'application APP et correspondant à l'identifiant ID_A.
[0160] Selon un mode de réalisation, l'enregistrement dans la mémoire cache C2 est conditionné par les résultats des deux comparaisons décrites ci-dessus et réalisées aux étapes Kl 03, Kl 04. En particulier, la donnée enregistrée D_C2 dans la mémoire cache C2 est remplacée lors de l'enregistrement par la donnée valide D_A3 reçue.
[0161] En particulier, suite à la réception d'une donnée valide D_A3 en provenance de l'application APP, le noyau KER détermine un haché H_A2 sur la base de l'identifiant ID_A et d'une fonction de hachage H2. Le noyau KER détermine ensuite, à l'étape K103, si une donnée enregistrée D_C2 dans la deuxième mémoire cache C2 partage un haché H_C2 identique au haché H_A2, i.e. H_C2=H_A2. Dans l'affirmative, le noyau KER compare, à l'étape K104, un compteur CNT_C2 associé à la donnée enregistrée D_C2 à un seuil THR _2. Selon un mode de réalisation, le seuil THR_2 est égal à 1. Si le compteur CNT_C2 est inférieur ou égale au seuil THR_2, alors le noyau KER enregistre, à l'étape K105, la donnée valide D_A3 reçue dans la deuxième mémoire cache C2, et en particulier dans la case mémoire stockant la donnée enregistrée D_C2.
[0162] Selon un mode de réalisation particulier de l'invention, la valeur d'un compteur CNT_C2 est déterminée de la manière suivante. La valeur d'un compteur CNT_C2 varie en fonction du nombre d'accès en lecture et en écriture à la donnée D_C2 dans la deuxième mémoire C2. À l'initialisation des entrées de la mémoire cache C2, les compteurs associés aux entrées sont initialisés à une valeur nulle. Si une donnée enregistrée D_C2' dans la mémoire cache C2 est invalide, alors le compteur CNT_C2 associé est nul ; et si la donnée D_C2 est valide, le compteur associé CNT_C2 est supérieur ou égal à 1. Si le compteur associé CNT_C2 est égal à 1, la donnée enregistrée C_2 est valide dans la mémoire cache C2 mais peut être évincée par une donnée reçue D_A3 en réponse à une requête GET_A. Lorsqu'une donnée D_C2 est enregistrée ou mise à jour dans la mémoire cache C2, le compteur associé CNT_C2 est mis à une valeur maximale MAX_CNT2. De même, lorsqu'une requête de lecture GET_C avec l'identifiant ID_C est interceptée et que la deuxième mémoire cache C2 comprend une donnée valide D_C2 correspondant à l'identifiant ID_C, alors le compteur associé CNT_C2 est mis à la valeur maximale MAX_CNT2.
[0163] En outre, pour une donnée enregistrée D_C2, la mémoire cache C_2 peut comprendre une valeur de concurrent CHA_C2 permettant d'identifier une donnée concurrente D_D. Ladite valeur de concurrent CHA_C2 est un haché déterminé sur la base de l'identifiant ID_D de la donnée concurrente D_D et d'une fonction de hachage G2, i.e. CHA_C2=G2(ID_D). Pour chaque donnée valide D_A3 reçue en provenance de l'application APP, le noyau KER détermine un haché de concurrent G2(ID_A) sur la base de l'identifiant ID_A et de la fonction de hachage G2. Si le compteur CNT_C2 est supérieur à 1, et que la valeur de concurrent CHA_C2 est différente du haché de concurrent G2(ID_A), i.e. CHA_C2*G2(ID_A), alors la valeur de concurrent CHA_C2 est remplacée par le haché G2(ID_A) associé à la donnée valide D_A3 reçue, i.e. G2(ID_A)^CHA_C2. Si le compteur CNT_C2 est supérieur à 1, et que la valeur de concurrent CHA_C2 est égale au haché de concurrent G2(ID_A), i.e. CHA_C2=G2(ID_A), alors le compteur CNT_C2 est décrémenté, i.e. CNT_C2-1^CNT_C2. Lorsqu'une donnée D_C2 est enregistrée ou mise à jour dans la mémoire cache C2, la valeur de concurrent CHA_C2 est mis à NULL.
[0164] De manière analogue, le noyau KER peut mettre en œuvre un enregistrement tel que décrit ci-dessus dans la première mémoire cache Cl d'une donnée valide D_A3 reçue en provenance de l'application APP en réponse à une requête GET_A. Dans ce cas, le noyau KER met en œuvre des étapes K113, K114, et K115 analogues aux étapes Kl 03, K104, et Kl 05 décrites ci-dessus pour enregistrer une donnée valide D_A3 dans la première mémoire cache Cl, et en utilisant un seuil THR_1, une fonction de hachage G1 et une valeur maximale MAX .CNT1. [0165] Ainsi, les différents niveaux de cache peuvent partager des structures de données et des procédés d'enregistrement de données similaires, bien que paramétrables indépendamment. Un des objectifs de ces étapes d'enregistrement est de maintenir dans les mémoires caches Cl, C2 les données fréquemment demandées en évitant que celles-ci ne soient remplacées par des données moins accédées. En outre, ces mécanismes d'enregistrements ont également pour objectif d'être exécutable en un temps minime afin de ne pas impacter négativement la latence de traitement des requêtes.
[0166] La figure 7A représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0167] Tel qu'illustré par la figure 7A, pour une donnée D_A1, la mémoire cache Cl comprend dans une de ses entrées : l'identifiant ID_A ; la donnée D_A1 ; un indicateur de validité V_A1 ; et un compteur CNT_A1.
[0168] Tel qu'illustré par la figure 7A, la validité d'une donnée D_A1, D_A2 dans une des mémoires caches Cl, C2 est caractérisée en utilisant un indicateur V_A1, V_A2. Typiquement, si la donnée D_A1, D_A2 est valide dans la mémoire cache Cl, C2, l'indicateur V_A1, V_A2 représentatif de la validité est égal à 1 ; et si la donnée D_A1', D_A2' est invalide dans la mémoire cache Cl, C2, l'indicateur V_A1, V_A2 est nul. Dans le présent document, les signes de référence des données valides D_A1, D_A2 sont différenciées des signes de référence des données invalides D_A1', D_A2', ces derniers se terminant par une apostrophe.
[0169] Selon un mode de réalisation particulier, la validité d'une donnée D_A1, D_A2 dans une des mémoires caches Cl, C2 est caractérisée en utilisant le compteur CNT_A1, CNT_A2 associé à la donnée D_A1, D_A2. Typiquement, si la donnée D_A1, D_A2 est valide dans la mémoire cache Cl, C2, le compteur CNT_A1, CNT_A2 représentatif de la validité est supérieur ou égal à 1 ; et si la donnée D_A1', D_A2' est invalide dans la mémoire cache Cl, C2, le compteur CNT.A1, CNT_A2 est nul.
[0170] La figure 7B représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0171] Dans le mode de réalisation décrit ici, la première mémoire cache Cl comprend une table de hachage TAB1. La table de hachage TAB1 permet une association directe clé-valeur, soit ID_A-D_A et permet ainsi retrouver une donnée rapidement, en la cherchant à un emplacement de la table TAB1 correspondant au résultat d’une fonction de hachage Hl. Ainsi, le procédé de traitement de requêtes comprend selon ce mode de réalisation particulier une étape de détermination d'un haché H_A1, le haché H_A1 étant calculé à partir de l'identifiant ID_A et de la fonction de hachage Hl. Le haché H_A1 permet de retrouver rapidement la donnée D_A1 dans la table TAB1. En particulier, le haché H_A1 peut être réduit à la taille de la table de hachage TAB1 via une opération de modulo pour obtenir l'index de l'entrée comprenant la donnée D_A1 dans la table TAB1.
[0172] De manière avantageuse, la fonction de hachage H1 utilisée est une fonction de hachage Fowler-Noll-Vo-1A, plus couramment désigné par l'acronyme FNV-1A. Cette fonction permet notamment de calculer le haché H_A1 tout en lisant une requête, permettant ainsi de réduire la latence due aux traitement des requêtes et plus généralement de gagner en performance par rapport à un calcul de haché réalisé a posteriori.
[0173] Par ailleurs, l'enregistrement d'une donnée D_A dans une table de hachage TAB1 tel que décrite ci-dessus comprend également l'enregistrement de l'identifiant ID_A de cette donnée D_A dans une entrée de la table de hachage TAB1. Les entrées d'une table de hachage TAB1 sont couramment dénommées alvéoles (ou avec les expressions anglo-saxonnes « buckets » ou « slots »).
[0174] Une telle structure de données offre une complexité en temps constant pour les opérations de recherche, d'insertion ou d'invalidation d'une donnée, ce qui permet de réduire la latence due aux traitements des requêtes et permet de traiter une charge importante avec un débit de requêtes élevé.
[0175] La figure 7C représente schématiquement un exemple de structures de données comprises dans une entité de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0176] Tel qu'illustré par la figure 7C, la deuxième mémoire cache C2 peut comprendre une table de hachage TAB2. La table de hachage TAB2 permet une association directe clé-valeur, soit ID_A-D_A. Ainsi, le procédé de traitement de selon ce mode de réalisation particulier comprend une étape de détermination d'un haché H_A2, le haché H_A2 étant calculé à partir de l'identifiant ID_A et d'une fonction de hachage H2. Le haché H_A2 permet de retrouver rapidement la donnée D_A1 dans la table TAB1. De manière avantageuse, la fonction de hachage H2 utilisée est une fonction de hachage Fowler-Noll-Vo-1A, plus couramment désigné par l'acronyme FNV-1A. Par ailleurs, l'enregistrement d'une donnée D_A dans une entrée de la table de hachage TAB2 comprend également l'enregistrement de son identifiant ID_A dans l'entrée.
[0177] Tel qu'illustré par la figure 7C, pour une donnée D_A, la table TAB2 de la deuxième mémoire cache C2 comprend dans une de ses entrées : l'identifiant ID_A ; la donnée D_A2 ; un indicateur de validité V_A2 ; un compteur CNT_A2 ; et une valeur de concurrent CHA_A2.
[0178] Bien évidemment, la première mémoire cache Cl peut comprendre une table de hachage TAB1 mettant en œuvre une structure de données telle que décrite ci-dessus. [0179] Selon un mode de réalisation particulier, les fonctions de hachage Hl, H2, Gl, et G2 et les valeurs maximales MAX_CNT1 et MAX_CNT2 sont paramétrées de manière différente pour la première mémoire cache Cl et la deuxième mémoire cache C2.
[0180] En effet, les différents mémoires caches Cl, C2 de l'architecture ont toutes deux pour but de stocker les données de l'application APP. Toutefois, chaque niveau de cache est paramétrable indépendamment l'un de l'autre afin de s'adapter aux contraintes matérielles des différents environnements d'exécution. Ce paramétrage permet notamment d'ajuster chaque niveau de cache aux ressources mémoires disponibles. La taille de la première mémoire cache Cl de la carte réseau NIC peut être différente de la taille de la deuxième mémoire cache C2 du noyau KER. Typiquement, la taille de la première mémoire cache Cl de la carte réseau NIC est inférieure à la taille de la deuxième mémoire cache C2 du noyau KER.
[0181] La figure 8A représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier.
[0182] À l'étape N210, la carte réseau NIC reçoit une requête d'accès en écriture SET_B comprenant un identifiant ID_B d'une donnée à écrire D_B. Typiquement, la requête SET_B est émise par un dispositif client CLT à destination de l'entité SERV.
[0183] À l'étape N240, la carte réseau NIC transmet la requête d'écriture SET_B au noyau KER.
[0184] À l'étape K270, suite à la réception de la requête d'écriture SET_B en provenance de la carte réseau NIC, le noyau KER transmet la requête d'écriture SET_B à l'application APP.
[0185] La figure 8B représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. En particulier, le procédé illustré par la figure 8B comprend en comparaison du procédé illustré par la figure 8A, les étapes supplémentaires suivantes.
[0186] Suite, à l'étape K270, la transmission par le noyau KER de la requête d'écriture SET_B à l'application APP, le noyau KER met en œuvre une étape K280.
[0187] À l'étape K280, le noyau KER reçoit une réponse REP_SET_B à la requête d'écriture SET_B comprenant un accusé de réception ACK émis par l'application APP en réponse à la requête d'écriture SET_B. Selon un mode de réalisation, le noyau KER transmet ensuite la réponse REP_SET_B à la carte réseau NIC.
[0188] À l'étape N290, la carte réseau NIC reçoit la réponse REP_SET_B et la transmet à l'étape N300 à destination du dispositif client CLT émetteur de la requête SET_B.
[0189] La figure 8C représente, sous forme d'ordinogramme, des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. [0190] À l'étape N210, la carte réseau NIC reçoit une requête d'accès en écriture SET_B comprenant un identifiant ID_B d'une donnée D_B à écrire. L'identifiant ID_B peut être identique ou différent de l'identifiant ID_A reçu à l'étape N10.
[0191] À l'étape N220, la carte réseau NIC détermine si la première mémoire cache Cl comprend une donnée D_B1 correspondant à l'identifiant ID_B.
[0192] À l'étape N230, si la première mémoire cache Cl comprend la donnée D_B1, la carte réseau NIC invalide la donnée D_B1' dans la première mémoire cache Cl, c'est-à-dire marque la donnée comme étant invalide.
[0193] À l'étape N240, la carte réseau NIC transmet la requête d'écriture SET_B au noyau KER.
[0194] À l'étape K250, suite à la réception de la requête d'écriture SET_B en provenance de la carte réseau, le noyau KER détermine si la deuxième mémoire cache C2 comprend une donnée D_B2 correspondant à l'identifiant ID_B compris dans la requête d'écriture SET_B.
[0195] À l'étape K260, si la deuxième mémoire cache C2 comprend une donnée D_B2 correspondant à l'identifiant ID_B compris dans la requête d'écriture SET_B, le noyau KER invalide la donnée D_B2' dans la deuxième mémoire cache C2.
[0196] À l'étape K270, le noyau KER transmet la requête d'écriture SET_B à l'application APP.
[0197] Après qu'une donnée D_B1', D_B2' a été invalidée dans une mémoire cache Cl, C2, une requête de lecture GET_B subséquente demandant la donnée D_B ne sera ni traitée par la carte réseau NIC ni par le noyau KER. Plutôt que d'utiliser la requête d'écriture SET_B pour mettre à jour l'entrée correspondante dans les différentes mémoires caches Cl, C2, le cache multi-niveaux utilise une donnée valide D_B3 émise par l'application APP en réponse à une requête GET_B et interceptée par le noyau KER ou la carte réseau NIC, ce qui permet de garantir la cohérence des données.
[0198] La figure 9 représente schématiquement des étapes d'un procédé de traitement de requêtes d'accès à des données selon un mode de réalisation particulier. En particulier, la figure 9 illustre la hiérarchie des mémoires caches Cl, C2 et de la mémoire d'application C3, ainsi que le traitement multi-niveaux des requêtes d'accès GET_A, SET_B.
[0199] Tel qu'illustré sur la figure 9, l'entité SERV reçoit en provenance d'un dispositif client CLT une requête GET_A demandant l'accès en lecture de la donnée D_A, la requête de lecture GET_A comprenant l'identifiant ID_A. La carte réseau NIC de l'entité SERV intercepte la requête GET_A et détermine si une donnée valide D_A1 correspondant à l'identifiant ID_A est enregistrée dans la première mémoire cache Cl. Dans l'affirmative, la carte réseau NIC est en mesure de répondre à la requête GET_A et ne transmet pas la requête GET_A au noyau KER. La carte réseau NIC lit la première mémoire cache Cl et transmet au dispositif client CLT une réponse REP_GET_A comprenant la donnée valide D_A1. Dans ce cas, l'entité SERV a traité et répondu à la requête GET_A sans solliciter le noyau KER ni l'application APP. Par conséquent, la latence d'accès aux données est réduite de manière significative et, en outre, l'utilisation des ressources matérielles et logicielles aussi.
[0200] Tel qu'illustré par la figure 9, dans le cas d'une requête de lecture GET_B comprenant un identifiant ID_B, si la première mémoire cache Cl ne comprend pas une donnée valide D_B1 correspondant à l'identifiant ID_B, la carte réseau NIC transmet la requête GET_B au niveau supérieur, le noyau KER. Suite à la réception de la requête GET_B, le noyau KER détermine si une donnée valide DB_2 correspondant à l'identifiant ID_B est enregistrée dans la deuxième mémoire cache C2. Dans l'affirmative, le noyau KER lit la donnée D_B2 et transmet à la carte réseau NIC une réponse REP_GET_B à la requête de lecture GET_B, la réponse REP_GET_B comprenant la donnée valide D_B2. La carte réseau NIC transmet au dispositif client CLT la réponse REP_GET_B. Dans ce cas, l'entité SERV a traité et répondu à la requête GET_B sans solliciter l'application APP, ce qui permet de réduire la latence d'accès aux données et d'économiser des ressources de traitement.
[0201] Tel qu'illustré par la figure 9, dans le cas d'une requête de lecture GET_C comprenant un identifiant ID_C, si la première et la deuxième mémoires caches Cl, C2 ne comprennent pas de données valides D_C1, D_C2 correspondant à l'identifiant ID_C, la carte réseau NIC transmet la requête GET_C au noyau KER ; et le noyau KER transmet la requête GET_C à l'application APP. Suite à la réception de la requête GET_C, l'application APP traite et répond à la requête GET_C. En réponse à la requête GET_C, l'application APP transmet une réponse REP_GET_C à la requête de lecture GET_C, la réponse REP_GET_C comprenant une donnée D_C3, au noyau KER, qui la transmet à son tour à la carte réseau NIC. Suite à la réception de la réponse REP_GET_C, la carte réseau NIC transmet au dispositif client CLT.
[0202] Tel qu'illustré par la figure 9, dans le cas d'une requête en écriture SET_D, la carte réseau NIC transmet la requête SET_D au noyau KER ; et le noyau KER transmet la requête SET_D à l'application APP. L'application APP traite la requête d'écriture SET_D et enregistre la donnée D_D dans la mémoire d'application C3. La transmission par la carte réseau NIC et le noyau KER des requêtes en écriture SET_D à l'application APP permet notamment d'assurer la cohérence des données D_D entre les différentes mémoires Cl, C2, C3. De plus, la carte réseau NIC et le noyau KER peuvent utiliser la requête d'écriture SET_D pour invalider dans les mémoires caches Cl, C2 des données D_D1', D_D2' correspondant à l'identifiant ID_D.
[0203] Un procédé et une entité SERV de traitement de requêtes d'accès à des données tels que proposés présentent les avantages suivants. Le traitement et la réponse à des requêtes de lecture GET par la carte réseau NIC et le noyau KER permettent de réduire de manière significative le temps de traitement des requêtes GET par l'entité, ces requêtes n'étant pas remontées à l'application APP. L'entité SERV est ainsi en mesure de réduire la latence d'accès aux données dans un réseau et d'augmenter le débit des requêtes traitées. En outre, le traitement de requêtes GET, SET par la carte réseau NIC ou le noyau KER est transparent pour l'application APP. La cohérence des données est garantie entre les différentes mémoires Cl, C2, C3, seules des données valides étant transmises en réponse aux requêtes GET. [0204] Il est à noter que l'ordre dans lequel s'enchaînent les étapes d'un procédé de traitement de requêtes d'accès tel que décrit précédemment en référence, notamment aux dessins ci-joints, ne constitue qu'un exemple de réalisation dépourvu de tout caractère limitatif, des variantes étant possibles. Par ailleurs, les signes de référence ne sont pas limitatifs de l'étendue de la protection, leur unique fonction étant de facilité la compréhension des revendications. [0205] Un homme du métier comprendra que les modes de réalisation et variantes décrits ci- dessus ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-dessus afin de répondre à un besoin bien particulier.

Claims

Revendications
[Revendication 1] Procédé de traitement de requêtes d'accès (GET_A) à des données, ledit procédé étant mis en œuvre par une entité (SERV) connectée à un réseau (NET), ladite entité (SERV) comprenant une carte réseau (NIC) et un noyau de système d'exploitation (KER), ledit procédé comprenant des étapes de :
• interception (N20) par la carte réseau (NIC) d'un paquet réseau à destination d'une application (APP) configurée pour traiter et répondre auxdites requêtes d'accès (GET_A), ledit paquet réseau portant une requête de lecture (GET_A) comprenant un identifiant (ID_A) d'une donnée (D_A) ;
• transmission (N50) par la carte réseau (NIC) de la requête de lecture (GET_A) au noyau (KER) en fonction de la présence d'une donnée (D_A1) correspondant audit identifiant (ID_A) dans une première mémoire cache (Cl) de la carte réseau (NIC) ; et
• émission (N130) par la carte réseau (NIC) d'une réponse (REP_GET_A) à la requête de lecture (GET_A), ladite réponse étant déterminée en fonction de la présence d'une donnée (D_A1, D_A2) correspondant audit identifiant (ID_A) dans la première mémoire cache (Cl) ou dans une deuxième mémoire cache (C2) du noyau (KER).
[Revendication 2] Procédé selon la revendication 1 caractérisé en ce que :
• la transmission (N50) de la requête (GET_A) par la carte réseau (NIC) au noyau (KER) est réalisée si la première mémoire cache (Cl) ne comprend pas une donnée (D_A1) correspondant audit identifiant (ID_A) ; et
• ladite réponse (REP_GET_A) comprend :
• si la première mémoire cache (Cl) comprend une donnée (D_A1) correspondant audit identifiant (ID_A), ladite donnée (D_A1) lue dans la première mémoire cache (Cl) ; ou
• si la deuxième mémoire cache (C2) comprend une donnée (D_A2) correspondant audit identifiant (ID_A), ladite donnée (D_A2) lue dans la deuxième mémoire cache (C2).
[Revendication 3] Procédé selon l'une des revendications 1 ou 2 comprenant, si aucune desdites mémoires caches (Cl, C2) ne comprend une donnée (D_A1, D_A2) correspondant audit identifiant (ID_A), une étape de :
• transmission (K80) de la requête de lecture (GET_A) à l'application (APP), ladite réponse (REP_GET_A) émise par la carte réseau (NIC) comprenant une donnée (D_A3) correspondant audit identifiant (ID_A), cette donnée (D_A3) étant émise par l'application (APP) en réponse à la requête de lecture (GET_A).
[Revendication 4] Procédé selon l'une des revendications 1 à 3 caractérisé en ce que :
• la requête de lecture (GET_A) est transmise (N50) par la carte réseau (NIC) au noyau (KER) si la première mémoire cache (Cl) ne comprend pas une donnée valide (D_A1) correspondant audit identifiant (ID_A) ;
• la requête de lecture (GET_A) est transmise (K80) par le noyau (KER) à l'application (APP) si aucune desdites mémoires caches (Cl, C2) ne comprend une donnée valide (D_A2) correspondant audit identifiant (ID_A) ; et
• ladite réponse (REP_GET_A) émise par la carte réseau (NIC) comprend une donnée valide (D_A1, D_A2, D_A3) correspondant audit identifiant (ID_A).
[Revendication 5] Procédé selon la revendication 3 ou 4 caractérisé en ce qu'il comprend une étape de :
• enregistrement (K100, K110) dans au moins une dite mémoire cache (Cl, C2) de ladite donnée (D_A3) reçue de l'application (APP) en réponse à la requête de lecture (GET_A), en fonction dudit identifiant (ID_A).
[Revendication 6] Procédé selon la revendication 5 caractérisé en que ladite étape d'enregistrement (K105, N125) est réalisée dans une dite mémoire cache (Cl, C2) en fonction d'au moins une des opérations suivantes :
• une comparaison (K103, N123) entre ledit identifiant (ID_A) compris dans la requête de lecture (GET_A) et un identifiant (ID_C) d'une donnée enregistrée (D_C1, D_C2) dans ladite mémoire cache (Cl, C2) ;
• une comparaison (K104, N124) entre un seuil (THR_1, THR_2) et un compteur (CNT_C1, CNT_C2) associé à une donnée enregistrée (D_C1, D_C2) dans ladite mémoire cache (Cl, C2).
[Revendication 7] Procédé selon l'une quelconque des revendications 1 à 6 caractérisé en ce qu'au moins une dite mémoire cache (Cl, C2) comprend une table de hachage (TAB1, TAB2), et en ce que ledit procédé comprend une étape de :
• détermination d'un haché (H_A1, H_A2) sur la base dudit identifiant (ID_A) compris dans la requête de lecture (GET_A) pour indexer une donnée (D_A1, D_A2) correspondant à l'identifiant (ID_A) dans ladite table (TAB1, TAB2).
[Revendication 8] Procédé selon l'une quelconque des revendications 1 à 7 caractérisé en ce qu'il comprend une étape de :
• si une dite mémoire cache (Cl, C2) comprend (N220, K250) une donnée (D_B1, D_B2) correspondant à un identifiant (ID_B) compris dans une requête d'écriture (SET_B), invalidation (N230, K260) dans ladite mémoire cache (Cl, C2) de la donnée (D_B1', D_B2') correspondant à l'identifiant (ID_B) compris dans la requête d'écriture (SET_B).
[Revendication 9] Entité de traitement de requêtes d'accès (GET_A) à des données, ladite entité (SERV) étant connectée à un réseau (NET), ladite entité (SERV) comprenant une carte réseau (NIC) et un noyau de système d'exploitation (KER), la carte réseau (NIC) comprenant une première mémoire cache (Cl), le noyau (KER) comprenant une deuxième mémoire cache (C2), ladite entité comprenant :
• un module de réception réseau (MOD_RX1) compris dans la carte réseau (NIC) pour intercepter un paquet réseau à destination d'une application (APP) configurée pour traiter et répondre auxdites requêtes d'accès (GET_A), ledit paquet réseau portant une requête de lecture (GET_A) comprenant un identifiant (ID_A) d'une donnée (D_A) ;
• un premier module de détermination (MOD_DET1) compris dans la carte réseau (NIC) pour déterminer la présence dans la première mémoire cache (Cl) d'une donnée (D_A1) correspondant audit identifiant (ID_A) ;
• un premier module de transmission (MOD_FWD1) compris dans la carte réseau (NIC) pour transmettre la requête de lecture (GET_A) au noyau (KER) ;
• un deuxième module de détermination (MOD_DET2) compris dans le noyau (KER) pour déterminer la présence dans la deuxième mémoire cache (C2) d'une donnée (D_A2) correspondant audit identifiant (ID_A) ; et
• un module d'émission réseau (MOD_TX1) compris dans la carte réseau (NIC) pour émettre une réponse (REP_GET_A) à la requête de lecture (GET_A).
[Revendication 10] Entité selon la revendication 9 caractérisé en ce que ladite entité (SERV) est un serveur DNS, lesdites données étant par exemple des adresses IP identifiées par des URLs, ou en ce que ladite entité (SERV) est un serveur de clés, comprenant par exemple des paires clé-valeur.
[Revendication 11] Programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque les instructions sont exécutées par un ou plusieurs processeurs (PROCI, PROC2).
[Revendication 12] Support d'informations lisible par ordinateur comprenant un programme d'ordinateur selon la revendication 11.
Abrégé
PCT/EP2023/056678 2022-03-22 2023-03-15 Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés WO2023180148A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2202542 2022-03-22
FR2202542A FR3133960A1 (fr) 2022-03-22 2022-03-22 Procédé de traitement de requêtes d’accès à des données, entité, programme d’ordinateur, et support d’informations associés

Publications (1)

Publication Number Publication Date
WO2023180148A1 true WO2023180148A1 (fr) 2023-09-28

Family

ID=82196326

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/056678 WO2023180148A1 (fr) 2022-03-22 2023-03-15 Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés

Country Status (2)

Country Link
FR (1) FR3133960A1 (fr)
WO (1) WO2023180148A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200314011A1 (en) * 2020-06-16 2020-10-01 Manasi Deval Flexible scheme for adding rules to a nic pipeline

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200314011A1 (en) * 2020-06-16 2020-10-01 Manasi Deval Flexible scheme for adding rules to a nic pipeline

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HERBERT BOS ET AL: "CacheCard", ARCHITECTURES FOR NETWORKING AND COMMUNICATIONS SYSTEMS, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 19 October 2009 (2009-10-19), pages 1 - 10, XP058323579, ISBN: 978-1-60558-630-4, DOI: 10.1145/1882486.1882491 *
TOKUSASHI YUTA ET AL: "LaKe: The Power of In-Network Computing", 2018 INTERNATIONAL CONFERENCE ON RECONFIGURABLE COMPUTING AND FPGAS (RECONFIG), IEEE, 3 December 2018 (2018-12-03), pages 1 - 8, XP033518143, DOI: 10.1109/RECONFIG.2018.8641696 *

Also Published As

Publication number Publication date
FR3133960A1 (fr) 2023-09-29

Similar Documents

Publication Publication Date Title
US11194719B2 (en) Cache optimization
US7398301B2 (en) Method and apparatus for facilitating distributed delivery of content across a computer network
US20100169442A1 (en) Apparatus and method for providing peer-to-peer proxy service with temporary storage management and traffic load balancing in peer-to-peer communications
US6983326B1 (en) System and method for distributed function discovery in a peer-to-peer network environment
US7055036B2 (en) System and method to verify trusted status of peer in a peer-to-peer network environment
US8316364B2 (en) Peer-to-peer software update distribution network
CN107094176B (zh) 用于对计算机网络上的数据通信进行缓存的方法和系统
US20060130045A1 (en) Systems and methods for dynamically updating computer systems
US20060167969A1 (en) Data caching based on data contents
EP1248438A2 (fr) Système et procédé de partage sécurisé et vérifié de ressources dans un environnement de réseau point à point
US9286293B2 (en) Populating and using caches in client-side caching
FR2918232A1 (fr) Procedes et dispositifs pour la communication de donnees de diagnostic dans un reseau de communication temps reel
WO2023180148A1 (fr) Procédé de traitement de requêtes d'accès à des données, entité, programme d'ordinateur, et support d'informations associés
WO2019063907A2 (fr) Procédé et dispositif de traitement d'une requête d'instanciation d'un service réseau
KR101145608B1 (ko) 네트워크의 토렌트 트래픽 선별 차단 방법
KR101364927B1 (ko) 네트워크의 토렌트 트래픽 선별 차단 방법
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
CA2433216A1 (fr) Serveur d'annuaire reparti
FR3107798A1 (fr) Procédé de gestion d’une requête d’accès à un site internet depuis un dispositif d’accès
EP3024181B1 (fr) Procede de communication de donnees entre un equipement radio itinerant et une passerelle d'acces reseau
WO2024129061A1 (fr) Addition fluide de blocs de serveur nfs
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
FR3140229A1 (fr) Procédé, dispositif et système de sélection d’au moins un dispositif apte à héberger un processus d’une application
CN116318841A (zh) 基于Web多级缓存的微应用帐号免登方法
FR3125191A1 (fr) Procédé d’établissement authentifié d’une connexion entre un équipement raccordé à au moins un réseau de communication et un serveur d’un fournisseur de services et dispositifs correspondants.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23728595

Country of ref document: EP

Kind code of ref document: A1