FR3078462A1 - METHOD AND DEVICE FOR CONTROLLING ACCESS TO A RESOURCE OF A COMPUTER SYSTEM BY SOFTWARE APPLICATIONS - Google Patents

Abstract

The control method comprises: - associating with each software application (APP1-APPN) a set of tokens (TB1-TBN), each token representing a predetermined access time to the resource; - upon receipt of a data packet for an application: ○ if the token set of this application includes at least one token, the processing of the packet and the decrementation of the set of tokens of the application of a number of tokens corresponding to the duration of access to the resource by the application during processing; ○ otherwise, rejection of the packet; - on detecting an update event relating to at least one subset of applications: ○ for each application of the subset, determining a number of tokens and adding the number of tokens determined to the set of application tokens within the limit of a maximum number; ○ if, for at least one application of the subset, the number of tokens determined is greater than the number of tokens added, and if there is at least one application whose set of tokens has a number of tokens less than the maximum number set for this application, the reassignment of the number of residual tokens to said at least one application.

Description

Invention background

The invention relates to the general field of computer systems and communication networks.

It relates more particularly to the control of access to resources of a computer system and in particular to its central processing unit (or CPU for Central Processing Unit in English) by a plurality of software applications executing on this computer system. . By software application here is meant a computer program or process capable of performing any type of processing.

Today we are witnessing an evolution in the way of building and implementing communication networks, in particular in order to meet the growing demand for new services. In particular, the recent paradigm of virtualization of network functions (or Network Function Virtualization (NFV) in English) proposes to implement network services in the form of software applications (or quite simply software) executing on computer systems. standard, not specialized. To achieve the required performance, the architecture of these software applications must be adapted and optimized for the processing of data packets exchanged on networks (also commonly referred to as “network packets”).

Software processing of network packets consists of executing a set of operations for each data packet received, both on the packet (such as updating or adding fields to the data packet) and / or on the computer system on which the software processing is carried out (such as updating a data structure for example) to optionally send the data packet to another computer system such as a virtual machine or another host. To carry out these operations, two approaches are generally considered:

- according to a first approach, each operation of the software processing to be carried out on the network packets is executed by a different process. When a process has completed performing the operation entrusted to it on a network packet, it transmits this network packet to the next process responsible for performing the next operation on the packet;

- according to a second approach, the network packets received are distributed between different processes, each process executing all of the operations to be performed on the packets which are allocated to it.

This second approach, commonly used, is also known as the “run-to-completion” model (or execution until completion in French). In other words, each network packet received by the process to which it is entrusted is processed completely by it (ie all the operations for which the process is in charge are executed by it on the network packet) before starting the processing of another network packet. This model avoids costly transmissions of network packets between different processes.

To take full advantage of the run-to-completion model on a computer system having a central processing unit or a multi-core processor, it is preferable to dedicate one or more CPU cores of the computer system to each process. Such a configuration makes it possible to avoid having to manage context changes (or “context switch” in English) between the different CPU cores of the computer system. Such context changes are particularly costly in CPU time: all the information relating to the process under consideration which in particular translates its state (eg flags, registers, instruction pointers, etc., manipulated by the process) must be saved in order to be able to execute the process on a new CPU core; similarly, the caches must be reset to zero on the new CPU core.

In addition, it is common to have several processes or several software applications for processing network packets running on the same computer system, in particular with a view to efficiently using the resources of this computer system. These different software applications may possibly be attached to different entities (for example to various clients of the computer system).

In such a context, there is the problem of sharing the resources of the computer system (and in particular of its CPU or of its multiple CPU cores) between the different software applications that it hosts to allow their execution. The “run-tocompletion” model somewhat complicates this sharing.

Indeed, in a classic preemptive scheduling model (or “preemptive scheduling” in English), it is customary to distribute access to the CPU core (s) of the computer system between the different software applications concerned. allocating to them CPU time units during which the software applications can each freely access the CPU core (s). If, for example, n units of CPU time are allocated to each application, n designating a positive integer, every n units of time, the application running on the CPU core considered is interrupted and replaced by another application of so as to ensure an equitable sharing of CPU time between the different applications. However, according to the “run-to-completion” model, the execution of an application (ie the processing of a network packet) cannot be interrupted until all the operations planned by this application are completed .

The approach adopted in the current state of the art for executing several software applications according to a “run-to-completion” model on the same multi-core host computer system, while guaranteeing an equitable distribution of the resources of the computer system between the different applications, consists in allocating in a dedicated way to each of the software applications one or more CPU cores. This approach has two major drawbacks, however.

First of all, it requires dedicating computer system resources to demultiplexing network packets to the different CPU cores: these resources can consist of one or more CPU cores, or the network card (s) of the system IT must be able to perform this demultiplexing itself.

In addition, this approach does not allow a very fine and consequently very efficient distribution of the resources of the computer system between the different applications. Typically, two software applications cannot share the same CPU core where one of them is allocated 1.5 CPU core while the other would have 2.5 CPU cores.

Subject and summary of the invention

The invention overcomes in particular the drawbacks of the state of the art by proposing a method of controlling access to a resource of a computer system by a plurality of software applications intended to run on the computer system. , this control process comprising:

A step of associating, with each software application, a dedicated set of tokens, each token representing a predetermined period of time of access to said resource;

- upon receipt of a data packet intended to be processed by a so-called software application:

o if the set of tokens associated with this software application includes at least one token:

a step of processing the data packet by the software application using the resource;

a step of decrementing the set of tokens associated with the software application by a number of tokens corresponding to a duration of access to said resource by the software application during the step of processing the data packet;

o otherwise, a step of rejecting the data packet; and - upon detection of at least one update event relating to at least one subset of software applications from the plurality of software applications, an update step comprising:

o for each software application of said subset:

a step of determining a number of tokens intended for this software application; and a step of adding the number of tokens determined to the set of dedicated tokens associated with this software application within the limit of a maximum number of tokens fixed for this software application; and o if, for at least one software application of the subset of software applications, the number of tokens determined is greater than the number of tokens added, and if there is at least one other software application of the plurality of software applications which is associated with a set of tokens having a number of tokens lower than the maximum number of tokens set for this other software application, a step of reassigning the residual tokens to said at least one other application.

Correlatively, the invention also proposes a device for controlling access to a resource of a computer system by a plurality of software applications intended to run on the computer system, each software application being associated with a dedicated set of tokens, each token representing a predetermined period of time of access to said resource, said control device comprising:

- an association module, configured to associate with each software application a dedicated set of tokens, each token representing a predetermined period of time of access to said resource;

- modules, activated on receipt of a data packet intended to be processed by a said software application, and comprising:

o a processing module and a decrementing module, activated if the set of tokens associated with this software application comprises at least one token, the processing module being configured to trigger the processing of the data packet by the software application using the resource, and the decrement module being configured to decrement the set of tokens associated with the software application by a number of tokens corresponding to a duration of access to said resource by the software application during the processing of the packet of data;

o a rejection module activated otherwise and configured to reject the data packet; and an update module activated on detection of at least one update event relating to at least one subset of software applications from the plurality of software applications, this update module comprising:

o a determination module and an addition module, activated for each software application of the subset, the determination module being configured to determine a number of tokens intended for this software application, and the addition module being configured to add the number of tokens determined for the set of tokens associated with the software application within the limit of a maximum number of tokens fixed for this software application; and o a reassignment module, activated if for at least one software application of the subset of software applications, the number of tokens determined is greater than the number of tokens added, and if there is at least one other software application of the plurality of software applications which is associated with a set of tokens having a number of tokens lower than the maximum number of tokens set for this other software application, this reassignment module being configured to reassign the residual tokens to said at least one other application.

Thus, the invention provides a mechanism for organizing the sharing, between several software applications of data packet processing, of a resource of a computer system, such as for example a resource of its central processing unit such as a core. CPU, perfectly compatible with a “run-to-completion” model according to which, when a software application performs processing on a data packet using this resource, it can access it until the processing is completed. This mechanism, instead of working directly to control access times to the resource as in the prior art, acts on (i.e. limit) the amount of data processed by each software application using the resource. Depending on the choice of the various parameters making it possible to act on this quantity of data, the invention leads to an equitable sharing of resources between the different software applications, or on the contrary to favor during this sharing one or the other of the software applications during this sharing. The mechanism proposed by the invention is easily configurable and offers a flexible solution for sharing the resources of a computer system.

To this end, the invention is based more particularly on a set of dedicated tokens allocated to each software application, a token representing a predetermined period of time of access to the resource considered. Each set of dedicated tokens may include a predetermined maximum number of tokens set for the associated software application.

The token sets associated with software applications are kept up to date according to the use of the resource by software applications. More specifically, each set of tokens dedicated to a software application is decremented each time the software application accesses the resource to process a data packet; this decrementation is carried out as a function of the time spent by the software application to carry out the complete processing of the package which has been entrusted to it (in accordance with the “run-to-completion” model, the software application is not interrupted as long as it has not completed processing the data packet entrusted to it). According to the invention, it can therefore happen that a set of tokens associated with a software application comprises at a given instant, following a decrementation, a negative number of tokens. In this case, it should be noted that only the packets intended for this software application will be impacted, as long as new tokens are not allocated to the software application.

In addition to this decrement reflecting the use of the resource by the software application, the token sets associated with the software applications are updated, and more particularly incremented, upon detection of an update event, and in the limit of a maximum number of tokens fixed for each software application. The invention is remarkable in that it reassigns all or part of the residual tokens which, because of this limit, are not added to the software applications of the subset, to other software applications. This allows a sharing of the computer system resource between the different software applications hosted by this computer system while taking into account the "run-to-completion" model adopted for the scheduling of the treatments implemented by these applications.

This approach is at first counter-intuitive, because it can lead to the rejection of certain packets when the software application for which they are intended no longer has access tokens for the resource, even when the resource is -be available. However, it allows a more efficient and more precise distribution of the resource between software applications than the state of the art when a "run-to-completion" model is envisaged. It is moreover all the more effective as the execution times of the treatments implemented by the software applications on the data packets are short.

The invention is also very simple to implement: it is in fact based on the provision and keeping up to date of a token counter (also called bucket of tokens or “token bucket” in English) dedicated and unique for each software application, which is incremented and decremented as a function of the use of the resource by the software application and of predetermined events. These token counters make it possible to finely manage the distribution of the resource considered between software applications competing to use this resource, by adapting the parameters for updating the counters (e.g. maximum number of tokens, speed of generation of new tokens or number of new tokens generated for each application, definition of the predetermined access period, update events, etc.). This flexibility and simplicity offers the possibility of easily allocating a fraction of a resource (for example a half-core CPU) to a software application in terms of access time, and to another software application another fraction of this same resource.

It should be noted that the use of counters or token buckets is known to limit the number of packets entering a system or a node of a computer network, or to limit the throughput passing through this system or this node. The so-called token bucket or pierced bucket algorithms are based, for example, on these concepts. The invention is remarkable in that it proposes to apply this concept to manage access to a resource of a computer system by considering tokens which correspond to a time of access to the resource.

In addition, thanks to the mechanism implemented to update the sets of tokens associated with software applications and in particular to the reassignment of residual tokens, the invention proposes a so-called "work-conserving" approach, consisting of always use the available resource as soon as a software application receives a data packet to be processed. Indeed, for example, if a CPU core of a computer system processor is shared between two programs, that one of the two programs has already reached its quota of access time to the CPU core (ie it has used all its tokens) and it still receives packets to be processed, access time to the CPU core not used by the second program can be reassigned to it when updating the token sets so as not to lose CPU resource.

Note that the previous example is given with reference to a resource of the CPU core type of a processor of a computer system. However, the invention applies to control access to other types of resources such as for example to control access to a hard disk of a computer system or to a network resource such as a network card for example, since access to this resource can be qualified (characterized) in terms of access time.

In accordance with the invention, new tokens allowing access to the resource are generated for the various software applications on detection of predetermined events.

In one embodiment, the detected update event is a predetermined update time for the subset among a plurality of update times spaced regularly in time.

This update makes it possible to reassign tokens periodically to the software applications which consume them, and this independently of the reception of the data packets.

It should be noted that the invention offers great flexibility with regard to the definition of the subset concerned by each updating step. We can for example define a plurality of subsets each containing a different software application: this amounts to updating the set of tokens associated with each software application at different times. As a variant, it is possible to define a subset containing all the software applications, which amounts to updating at the same time the token sets of the different software applications considered.

This embodiment, in which the updating steps are decorrelated from the execution of the processing operations on the data packets, requires the management of concurrent access to the sets of tokens associated with the different software applications. Indeed, in accordance with the invention, the sets of tokens are decremented on the one hand after execution of the processing operations and they are incremented on the other hand, during the updating steps. Synchronization between the generation of new tokens and their use by software applications to access the resource is therefore desirable. This synchronization can be achieved by various means, such as by means of a software lock intended to prevent simultaneous access to the same set of tokens on the one hand to increment it, and on the other hand, to verify its content. and decrement it when processing a data packet.

The implementation of such synchronization can result in latencies, for example induced due to the waiting time required until the release of the lock before being able to start a treatment.

In another embodiment, the update event detected is the reception of a data packet intended to be processed by a said software application. Preferably, the update step is then carried out before the processing of the data packet received by the software application.

In other words in this embodiment, the updating of the token sets takes place no longer at regular intervals but as a function of the reception of the data packets to be processed.

In a particular embodiment, it is however ensured that two successive steps for updating the token sets are spaced at least by a predetermined time interval, in order to avoid too frequent updating of the token sets. which can itself consume computer system resources.

In a particular embodiment, during the determination step, the number of tokens intended for a software application is determined from a token generation speed set for this software application.

The time of access to the resource by the software applications to process the received packets is thus a function of the token generation speed.

The same generation speed can in particular be fixed for each of the software applications of the plurality of software applications, in order to obtain an equitable sharing of resources between the different software applications.

As a variant, separate token generation speeds can be considered for the different software applications, for example as a function of priorities which it is desired to assign to one or the other of the software applications.

In a particular embodiment, the control method comprises during the updating step:

A step of evaluating a global number of residual tokens for the subset of software applications;

A step of identifying, among said plurality of software applications, software applications associated with dedicated sets of tokens which after the adding step comprise numbers of tokens lower than the maximum numbers of tokens set for these software applications; and a step of distributing all or part of the overall number of residual tokens between the identified software applications within the limit of the maximum number of tokens set for the identified software applications.

In addition, as long as at the end of the distribution step, there are residual tokens and at least one software application associated with a set of tokens comprising a number of tokens less than the maximum number of tokens set for this software application can be identified, these residual tokens can be distributed between said at least one software application that can be identified.

This embodiment promotes in a simple and effective manner a “work-conserving” type of operation. All residual tokens are reassigned between software applications so that they can use the available resource when it is required to process a packet received by a software application. This allows an adapted and precise distribution of the computer system resource according to the needs of software applications.

In a particular embodiment, the same maximum number of tokens is fixed for each of the software applications of said plurality of software applications.

The maximum number of tokens set for each software application affects the execution of software applications and the stability of the computer system. Preferably, this maximum number is chosen so as not to “hatch” the executions of the software applications too much (one typically avoids that an application consumes all of the tokens dedicated to it too quickly then remains inactive for a long time).

The same maximum number of tokens set for all software applications makes it possible to facilitate the implementation of the invention and in particular the dimensioning of its operating parameters.

In a particular embodiment, the different steps of the control method are determined by instructions from computer programs.

Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a control device or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a control process as described above.

This program can 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 form.

The invention also relates to an information or recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.

The information or recording medium can be any entity or device capable of storing the program. For example, the support may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or also a magnetic recording means, for example a hard disk.

On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from a network of the Internet type.

Alternatively, the information or recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

The invention also relates to a computer system comprising:

- a plurality of data processing software applications intended to run on the computer system and to access at least one resource of the computer system during their execution; and a device for controlling access to said at least one resource by the plurality of software applications according to the invention.

It can also be envisaged, in other embodiments, that the control method, the control device and the computer system according to the invention have all or some of the above characteristics in combination.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an embodiment thereof devoid of any limiting character. In the figures:

- Figure 1 shows, schematically, a computer system and a control device according to the invention in a particular embodiment;

- Figures 2A and 2B shows, in the form of a flowchart, a control method according to the invention in a first embodiment, when it is implemented by the control device of Figure 1; and FIG. 3 represents, in the form of a flowchart, a control method according to the invention in a second embodiment, when it is implemented by the control device of FIG. 1.

Detailed description of the invention

FIG. 1 represents, in its environment, a computer system 1 according to the invention, in a particular embodiment.

In the example illustrated in FIG. 1, the computer system 1 is a computer, equipped with a processor 2 (or central processing unit) single or multi-core: it includes K cores CPU denoted CPU1, CPU2, ... , CPUK, K designating an integer greater than or equal to 1. The computer system 1 hosts in this example a plurality of software applications (ie of computer programs) APP1, APP2, ..., APPN, N designating an integer greater than 1 , able to apply various processing operations on data packets, and to use the processor 2 of the computer system 1 to carry out these processing operations. Each of the treatments carried out may include one or more operations. We place ourselves here, by way of illustration, in a context of network function virtualization (NFV) as mentioned above, and we assume that the processing implemented by software applications APP1, APP2, ..., APPN, are processing intended to be applied to network data packets (ie exchanged within a communication network). Such processing consists, for example, of modifying / adding or removing a header from a packet, of verifying the legitimacy of a packet according to access control rules, of aggregating statistics from packets (to implement for example a supervisory function), etc.

This example is however considered for illustrative purposes only and the invention can be applied in other contexts, to other types of processing and / or data packets, etc. The computer system 1 can also alternatively comprise a plurality of computers or other hardware elements, which can be linked together for example via a telecommunications network (wired or wireless).

In accordance with the invention, the computer system 1 comprises a device 3 for controlling access by the software applications APP1, ..., APPN hosted by the computer system 1 to the resources of the computer system 1, and more particularly here, at its processor 2 and its CPU core (s), CPU1, ..., CPUK, Each CPU core here constitutes a resource of the computer system 1 within the meaning of the invention. It should be noted that the invention can also be applied to other resources of the computer system 1, such as for example a hard disk, or to network resources (eg network card), etc., provided that it is possible to qualify or characterize access to these resources in terms of access time.

The control device 3 is configured here to apply a “run-tocompletion” model for the scheduling of the various processing operations carried out by the software applications ΑΡΡΙ,.,., ΑΡΡΝ on the network data packets which are entrusted to the computer system 1, and manage access to processor 2 to execute these treatments. In the embodiment described here, it is assumed that a single core CPU of the processor 2 of the computer system 1, namely the core CPU1, is dedicated to the execution of the software applications ΑΡΡΙ,.,., ΑΡΡΝ. If several CPU cores are dedicated to software applications ΑΡΡΙ,.,., ΑΡΡΝ, for the execution of their processing, access to each of these CPU cores is managed by the control device 3 in the same way as what is described below for the CPU1 core.

According to the “run-to-completion” model, each software application APPn, n = l, ..., N, when it receives a data packet intended for processing, performs all of the operations provided for by this processing on this packet using the core CPU1 without being interrupted by the control device 3: in other words, access to the core CPU1 of the processor 2 is ensured until the processing it executes on the data packet.

It is noted that the invention applies regardless of the quantity of resource CPU of the core CPU1 of the processor 2 allocated strictly speaking to the applications ΑΡΡΙ,.,., ΑΡΡΝ to execute their processing. It is assumed here for the sake of simplification that the applications ΑΡΡΙ,.,., ΑΡΡΝ are able to use all the time of access to the core CPU1 of the processor 2, and that the control device 3 makes it possible to control this concurrent access by the applications ΑΡΡΙ,.,., ΑΡΡΝ to this CPU resource.

As a variant, only a fraction of the possible access time to the core CPU1 can be allocated to the applications ΑΡΡΙ,.,., ΑΡΡΝ (for example 75%), the remaining fraction being able to be dedicated to other applications or processes managed by the computer system 1. How this adjustment can be made is described in more detail later. In the following description, for the sake of simplicity, reference is made generally to "the CPU resource" to designate the part of the core CPU1 dedicated to applications APP1,..., APPN for the execution of their processing.

According to the invention, to control access to the core CPU1 of processor 2, the control device 3 associates, via an association module 3A provided for this purpose, with each software application APP1, ..., APPN hosted by the computer system 1 a dedicated set (also called bucket in the following description) of access tokens for the processor 2. Each token represents a predetermined period T of access time to the resource CPU1; this time period T defines in the context of the invention a “CPU time unit” (or a unit of access time to the resource CPU1) allocated to the applications, such as for example a nanosecond of CPU time, the time CPU here designating the duration during which the CPU resource considered (ie the core CPU1 here) is active, that is to say the time during which it can be accessed. This CPU time does not typically count the interruptions of access to the CPU1 core: a nanosecond of CPU time can thus in itself be distinct from a nanosecond. The quantity of tokens allocated to each software application ΑΡΡΙ,.,., ΑΡΡΝ is described in more detail later.

Each bucket of tokens noted TBn, n = l, ..., N associated with a software application APPn can contain a maximum number of tokens Bn. For the sake of simplification, it is assumed here that the same maximum number of tokens B is fixed for all the software applications ΑΡΡΙ,.,., ΑΡΡΝ, that is to say B1 = B2 = ... = BN = B. The maximum number B can be chosen experimentally, as described in more detail later.

As a variant, different numbers Bn, n = l, ..., N can be envisaged.

The control device 3 manipulates the different buckets of tokens TBn, n = l, ..., N to control access to the resource CPU considered of the computer system 1 (the core CPU1 in the example envisaged here). To this end, it comprises a plurality of functional modules relying on or controlling various hardware means of the computer system 1 (for example a random access memory, a read-only memory, a non-volatile memory, means of communication, etc., which is conventionally provided a computer system and here the computer system 1) and implementing the control method according to the invention. These functional modules are here software modules defined by instructions of a computer program PROG according to the invention. The computer program PROG is stored in a read only memory 4 of the computer system 1 readable by the processor 2. It includes instructions for the execution of the steps of the control method according to the invention implemented by the control device 3 The read-only memory 4 thus constitutes a recording medium in accordance with the invention, on which the computer program PROG is recorded.

The PROG computer program defines the following functional modules of the control device 3:

- an association module 3A already mentioned, configured to associate with each of the software applications ΑΡΡΙ,.,., ΑΡΡΝ the token buckets ΤΒΙ,.,., ΤΒΝ respectively;

- modules, activated on reception by the control device 3 of the computer system 1, of a data packet intended to be processed by one of the software applications ΑΡΡΙ,.,., ΑΡΡΝ (denoted APPj in the following) and including:

o a module 3B for inspecting the set, or bucket, of tokens TBj associated with the software application APPj;

a processing module 3C and a 3D decrementing module, activated if the inspection module 3B determines that the bucket of tokens TBj comprises at least one token. The processing module 3C is configured to trigger the processing of the data packet by the software application APPj if the token bucket TBj comprises at least one token. The 3D decrementation module is configured to decrement the bucket of tokens TBj by a number of tokens corresponding to the duration of the processing carried out by the software application APPj on the data packet (this duration characterizes the time of access to the resource CPU1 by the software application APPj for processing the data packet);

o a rejection module 3E activated if the inspection module 3A determines that the bucket TBj does not contain at least one token, and configured to reject the data packet; and - an update module 3F, activated on each detection of an update event relating to one or more subsets SI, ..., SL of software applications of the plurality of software applications, L designating an integer greater than or equal to 1. No limitation is attached to the way in which the subsets are defined. The subsets S1, ..., SL are disjoint (i.e. they do not include any common software application (s)). By way of illustration, L can be taken equal to 1 and the subset SI contain all of the software applications ΑΡΡΙ,.,., ΑΡΡΝ. According to another example, we can consider L = N subsets each consisting of a single distinct software application. We denote by N (S) the number of software applications included in each subset S, S = S1, ..., SL, and by I (S) the set of indices of software applications of the plurality of software applications ΑΡΡΙ,.,., ΑΡΡΝ included in this subset S. According to the invention, the update module 3F comprises:

o a 3F1 determination module and a 3F2 addition module, activated for each software application APPi, iel (S) of the subset S considered, the 3F1 determination module being configured to determine a number of tokens ri intended for this application APPi software, and the 3F2 adding module being configured to add the determined number of tokens ri to the dedicated token bucket TBi associated with the APPi software application within the limit of the maximum number Bi (= B here) of tokens set for this software application; and o a 3F3 reassignment module, activated if for at least one software application denoted APPm of the subset S, the number of tokens rm determined by the determination module 3F1 is greater than the number of tokens added by the addition module 3F2 to the TBm token bucket (this added number of tokens is in fact equal to min (Bm-bm, rm) where bm denotes the number of tokens already present during the update in the TBm token bucket, bm can be positive , negative or zero). The 3F3 reallocation module is configured to reassign the residual tokens (in other words, the rm-min (Bmbm, rm) residual tokens for each APPm application concerned) to at least one other application of said plurality of software applications ΑΡΡΙ,., .ΑΡΡΝ.

The functions of these modules are now described in more detail, with reference to the steps of the control method according to the invention.

According to the invention, the control method is based on two processes:

- a first process PROC1 which aims, strictly speaking, to manage an incoming PKT data packet intended for one of the software applications APP1, ..., APPN. This process PROC1 aims more particularly to identify the software application for which the PKT packet is intended, to determine whether it is, in view of the current state of its bucket of tokens, able to process this packet, and if necessary , to update (more precisely to decrement in the case of the PROC1 process) the number of tokens contained in the bucket of the software application as a function of the time of access to the resource CPU1 consumed by the software application for the processing of the package; and - a second process PROC2 which aims to update, upon detection of update events, the token buckets associated with the software applications APP1, ..., APPN and more precisely to increment the number of tokens contained in these buckets within the limit of the maximum numbers fixed for them.

In other words, the control method implements two types of token bucket updates associated with software applications: a decrementation of the number of tokens contained in the bucket when the software application has consumed the resource to process a packet of data, and an incrementation of the number of tokens upon detection of predetermined events.

We will now describe in more detail each of the processes PROC1 and PROC2 in several embodiments of the invention.

In a first embodiment, shown in FIGS. 2A and 2B, the two processes are carried out independently of one another.

More precisely, in the first embodiment, the process PROC1 (illustrated in FIG. 2A) is implemented by the control device 3 on reception of a packet of PKT data to be processed, while the process PROC2 (illustrated in FIG. 2B) is implemented at predetermined update times, fixed for each subset S1, ..., SL. The event triggering the update operated by the PROC2 process (incrementing the token buckets) is therefore here the detection of a predetermined update time, fixed for each subset SI, ..., SL. One carries out here, for each subset SI, 1 = 1, ..., L, an update according to the process PROC2 at times of update regularly spaced in time.

Figure 2A illustrates the steps in the PROC1 process.

When a PKT data packet to be processed is received by the control device 3 (step E10), the control device 3 firstly determines which software application among the software applications ΑΡΡΙ,.,., ΑΡΡΝ this PKT packet is intended (step E20). To this end, the control device 3 examines for example the values of one or more headers of the PKT packet and uses associations (value (s), application) to determine the software application intended for this packet.

It is assumed here that the PKT data packet is intended for the software application APPn. Then the control device 3, via its inspection module 3B, determines whether the bucket TBn of tokens associated with the software application APPn comprises at least one token, otherwise if bn (number of tokens included in the bucket TBn at the current time) is greater than or equal to 1 (test step E30).

If the bucket TBn does not contain at least one token (response no to step E30), ie the number of tokens bn is negative or zero, the PKT packet is rejected by the rejection module 3E of the control device 3 (step E40). It is for example deleted by the 3E rejection module. In other words, it is not treated.

If the bucket TBn contains at least one token (answer yes in test step E30), the processing module 3C of the control device 3 transmits it to the software application APPn and triggers the processing of the PKT packet by the software application APPn (step E50). The software application APPn has free access to the resource CPU1 and can execute without being interrupted the various processing operations which it must apply to the PKT packet. The duration noted tf-td during which the resource CPU1 is used by the software application APPn during the processing of the PKT packet is measured by the resource CPU1. This duration characterizes the duration of access to the resource CPU1 by the software application during the processing of the PKT packet.

At the end of the processing of the PKT packet by the software application APPn, the token bucket TBn of the application APPn is updated (step E60).

More specifically, the number of tokens bn contained in the bucket TBn is decremented by the 3D decrementation module of the control device 3 by a number of tokens noted here dn. This number of tokens dn corresponds to the duration of access to the resource CPU1 by the software application APPn during the processing of the PKT data packet, ie at tf-td. This duration characterizes the duration during which the software application APPn was able to freely access the resource CPU1 to process the data packet PKT during the processing step E50 without being interrupted by another application. It is quantified here by the 3D decrementation module in CPU time units (of duration T each): in the example envisaged here, the decrementation module 3C estimates this access time at dn.T, each token corresponding to a CPU time unit (of duration T) as indicated previously. We note that it is possible that dn.T is not exactly equal to tf-td depending on the values of dn and T, dn being an integer (we have (dn-l) .T <tf-td < dn.T).

This step of decrementing E60 ends the process PROC1. The control device 3 then waits for reception of a new packet to be processed. The steps of the process PROC1 are repeated for each new data packet received by the control device 3 and intended for a software application ΑΡΡΙ ,,. ,, ΑΡΡΝ.

As mentioned previously, in the first embodiment, the control device 3 implements, on the fringes (that is to say independently) of the reception of the data packets to be processed (in other words, on the fringes of the process PROC1 ), the process PROC2 aimed at generating new tokens for accessing the resource CPU1 for the software applications ΑΡΡΙ ,,. ,, ΑΡΡΝ. This process PROC2 is illustrated in FIG. 2B and is implemented for each subset SI ,, .., SL as soon as the instants for updating these subsets are detected (step F10). The times for updating the subsets S1, ..., SL are spaced regularly over time. We note ûtl the time interval separating two updates according to the process PROC2 for the subset SI, 1 = 1, ..., L. The same time interval Atl can be chosen for all the subsets SI or different time intervals. Likewise, the updates of the different subsets can be out of sync with one another (i.e. carried out at times tOI + Atl with different tOI depending on the subsets SI).

In the following description, it is considered that an update time relating to the subset of software applications S (S being one of the subsets S1, ..., SL mentioned above) is detected during of step F10 (update event within the meaning of the invention). We denote by I (S) the set of indices of the software applications belonging to the subset S and by AtS the time interval separating two updates for the subset S.

New access tokens are then generated by the control device 3 for the software applications APPi, iel (S), via its update module 3F. The actual generation of new tokens according to the PROC2 process takes place in three stages F20 to F40.

During this generation, for each software application APPi, iel (S), the control device 3, via its determination module 3F1, first of all determines a number of tokens ri intended for the software application APPi, and more particularly , to be added to its bucket of tokens TBi (ie to the bi tokens already present in the bucket of tokens TBi, bi denoting the current number of tokens present in the bucket TBi) (step F20). In the embodiment described here, the number of tokens ri is determined from a token generation speed set for the software application APPi. We note vi this speed; it is expressed in tokens per second, in other words here in units of CPU time per second.

The same token generation speed v for all the software applications ΑΡΡΙ ,,. ,, ΑΡΡΝ can be envisaged. As a variant, it is possible to envisage separate generation speeds as a function of the software applications APPi, i = l, ..., N. The sum of the generation speeds determines the percentage of the access time to the resource CPU1 that the operator of the computer system 1 is ready to allocate to the software applications APPi, i = 1, ..., N.

Thus, for example, if each token represents a nanosecond of CPU time (ie of the access time to the resource CPU1 here), this means that the control device 3 has 10 ⁹ tokens to allocate between the software applications APP1 ,. .., APPN if the CPU1 core is entirely dedicated to these applications. It may alternatively be decided by the operator of the computer system 1 to allocate only a fraction of the 10 ⁹ tokens to software applications APP1, ..., APPN (for example 80%). If we denote by a the fraction of CPU time dedicated by the operator to software applications ΑΡΡΙ,.,., ΑΡΡΝ and NbT the number of tokens available each second, the sum of the speeds vi of generation of the tokens, i = l ,. ..N, check the relation:

N = a. NbT i = l

Thus, if the same generation speed vi = v, i = l, ..., N is fixed for all the software applications ΑΡΡΙ,.,., ΑΡΡΝ, the tokens are distributed equitably between the applications.

The operator of the computer system 1 can, as a variant, decide to prioritize certain software applications APPi by assigning them token generation speeds higher than the other applications.

From the generation speed vi, the determination module 3F1 determines the number of tokens to be generated ri as follows:

ri = vi.ûtS for iel (S).

Among the new tokens generated, due to the maximum number of tokens set for each bucket of tokens and the current state of the token buckets of APPi, iel (S) software applications, some tokens may not be able to be effectively allocated to applications for which they were originally intended. These tokens are said to be residual. The control device 3 evaluates, via its reallocation module 3F3, the overall number of these residual tokens if there are any (step F30) for all of the software applications of the set I (S). This overall number of residual tokens, noted r ', is evaluated by the 3F3 reallocation module as follows:

r '= (ri - min (B - bi, ri)) ie! (S) where bi denotes the number of tokens running in the bucket TBi of the software application APPi as mentioned previously.

Then the control device 3 adds, by means of its addition module 3F2, to each bucket TBi associated with each software application APPi of the set I (S), the number of tokens ri determined for this software application APPi in the limit of the maximum number of tokens Bi defined for it (step F40): the adding module 3F2 thus adds to each bucket TBi of tokens associated with a software application APPi, iel (S), mîn (Bi-bi, ri) tokens (ie min (B-bi, ri) in the example envisaged here where Bi = B). At the end of this step, each bucket of tokens TBi, iel (S) therefore contains a number of tokens equal to min (B, bi + ri): this is the new current number bi of tokens contained in the bucket TBi of the APPi, iel (S) software application.

If the number ri of residual tokens evaluated in step F30 is zero (answer no in test step F50), the updating process PROC2 is completed (step F120).

In accordance with the invention, if on the contrary the overall number ri of residual tokens evaluated in step F30 by the control device 3 is greater than 0 (answer yes in test step F50), the residual tokens which have not software applications that have reached their maximum number of tokens cannot be added to the buckets and are reassigned by the 3F3 reallocation module to other software applications, or at least to those that have not yet reached their maximum number of tokens, and this , within the limit of this maximum number of tokens.

In the embodiment described here, we consider for the reassignment of residual tokens all software applications APP1, ..., APPN which have not reached their maximum number of tokens. The reallocation module 3F3 therefore first identifies the software applications APPj among the applications ΑΡΡΙ ,,. ,, ΑΡΡΝ for which, at the end of step F40, the current number bj of tokens present in their bucket TBj is lower than the maximum number of tokens Bj = B set for these applications (step F60). We denote by J the set of indices of software applications satisfying this condition.

Then, the 3F3 reallocation module distributes between the software applications thus identified all or part of the overall number ri of residual tokens evaluated within the limit of the maximum number of tokens set for the software applications identified in the set J. More precisely here, it reassigns the residual tokens to the software applications identified in the set J as a function of their respective generation speeds (ie in proportion to these speeds). To this end, it determines, for each of the software applications APPj, jeJ, a number of tokens rj intended for this application by applying the following relation (step F70):

As in step F30, among the residual tokens ri, due to the maximum number of tokens set for the token buckets of the software applications identified in the set J and the current state of these buckets, it may be that certain tokens cannot be allocated to the applications to which they were intended during step F70 (in other words that for certain software applications of the set J, only part of the rj tokens intended for these applications can be added to their buckets respectively). The reallocation module 3F3 thus reassesses the overall number ri of the residual tokens by means of the following relation (step F80):

Then the adding module 3F2 adds, to each bucket TBj dedicated to each software application APPj, jeJ, the number of tokens rj determined during step F70 for this software application APPj within the limit of the maximum number of tokens Bj defined for this one (step F90): in other words, it adds to each bucket TBj of tokens associated with a software application APPj of the set J, min (Bi-bj, rj) tokens (i.e. min (B-bj , rj in the example considered here where Bj = B for j = l, ..., N).

At the end of this step F90, each bucket of tokens TBj associated with a software application APPj therefore contains a current number of tokens equal to min (B, bj + rj): this number constitutes the new current number of tokens bj contained in the bucket TBj, jeJ.

The reassignment module 3F3 checks whether there are residual tokens to be reassigned between the software applications, in other words if r 'is greater than 0 (test step F100).

If r 'is zero (response no at test step F100), the update carried out by the process PROC2 is completed (step F120).

If there are still tokens to be reassigned (ie r '> 0, answer yes in the test step F100), the reassignment module 3F3 checks whether there is at least one software application APPjO among the applications identified in the set J having a bucket of tokens containing a number of current tokens bjO lower than the maximum number of maximum tokens BjO fixed for this software application (test step F110).

If there is no application verifying this condition (response no to the test step F110), the update carried out by the process PROC2 ends (step F120).

If there is at least one application verifying this condition (answer yes at the test step Fl 10), then the steps of identification F60, determination F70, reassessment F80, addition F90 and test F100 are repeated for said at least one application, until the number of residual tokens r 'is zero or until all the buckets associated respectively with software applications APP1, ... APPN have reached their maximum number of tokens (responses no to test steps F90 and F100). This closes the update carried out by the PROC2 process (step F120).

Note that to allow processes PROC1 and PROC2 to run in parallel independently of each other, we can consider using software locks allowing for example, when the process PROC1 to prevent access to software application buckets ΑΡΡΙ,.,., ΑΡΡΝ by the PROC2 process and vice versa, so as to avoid concurrent access to the buckets by the two processes. The use of such software locks is known per se and is not described in detail here.

As a variant, it is possible to envisage synchronizing the execution of one process with respect to the other, so as to prevent these two processes from executing at the same time and carrying out a concurrent update of the token buckets of the applications. APP1, ...., APPN software.

FIG. 3 represents a second embodiment of the invention in which the process PROC2 and the generation of new tokens for the software applications ΑΡΡΙ ,,.,., ΑΡΡΝ are carried out at irregular intervals, and does not require managing a simultaneous access to the software application buckets ΑΡΡΙ,.,., ΑΡΡΝ by the two processes PROC1 and

PROC2.

In this second embodiment, the triggering event (step F10) of the update carried out by means of the PROC2 process is the reception by the control device 3 of a PKT data packet intended to be processed by one (at least) software applications APP1, ... APPN (step E10 described previously with reference to FIG. 2A). The control device 3 also checks whether the last update dates from more than a predetermined time interval Δ (test step G10), in order to ensure that two successive updates of the token buckets of the applications APP1, ..., APPN are spaced at least the time interval Δ.

If this is the case (answer yes in test step G10), the control device 3 triggers the updating of the token buckets according to the process PROC2 (step G20), in an identical manner to what has been described for the first embodiment with reference to FIG. 2B. During this update, it can consider a subset S of software applications previously selected from a plurality of subsets SI, ... SL, each subset SI, 1 = 1, ..., L comprising one or more software applications among the applications APP1, ..., APPN, the subsets S1, ..., SL being disjoint as in the first embodiment: in this case, the selected subset S is the subset among the subsets S1, ..., SL which comprises the software application APPn for which the PKT packet is intended. As a variant, during the update according to the process PROC2, the control device 3 can consider all of the software applications ΑΡΡΙ,.,., ΑΡΡΝ (ie the subset S here includes all the software applications APP1 ,. .., APPN). The PROC2 process is applied by considering Atl = AtUPD _s , where AtUPD _s denotes the time interval separating this update from the last update carried out by the control device 3 according to the PROC2 process for the subset S.

Otherwise (response no to test step G10), the control device 3 directly executes the process PROC1 for processing the data packet PKT received in step E10 (step G30) and no update according to the process PROC2 is done.

At the end of the update carried out if necessary during step G20, the control device 3 triggers the processing of the PKT packet via the process PROC1 (step G30), as described previously in the first embodiment in reference to Figure 2A.

Note that whatever the embodiment envisaged, the PROC2 process can be implemented during a step of initialization of the token buckets associated with the different software applications ΑΡΡΙ,.,., ΑΡΡΝ to assign tokens to these different applications even before receiving a data packet. As a variant, it is possible to envisage assigning, during this initialization step, to each software application ΑΡΡΙ,.,., ΑΡΡΝ the same predetermined number of tokens or a number of different tokens (equal for example to the maximum number of tokens ΒΙ,. ,,., ΒΝ).

Claims (16)

1. Method for controlling access to a resource (CPU1) of a computer system (1) by a plurality of software applications (ΑΡΡΙ,.,. ΑΡΡΝ) intended to run on the computer system, the method control including: A step of association, with each software application, of a dedicated set of tokens (ΤΒΙ,.,., ΤΒΝ), each token representing a predetermined period of time of access to said resource; - on reception (E10) of a data packet (PKT) intended to be processed by a said software application: o if the set of tokens associated with this software application includes at least one token (E30): a step of processing (E50) the data packet by said software application using said resource; a step of decrementing (E60) the set of tokens associated with the software application by a number of tokens corresponding to a duration of access to said resource by the software application during the step of processing said packet; o otherwise, a rejection step (E40) of the data packet; and - upon detection of at least one update event relating to at least one subset of software applications from the plurality of software applications (F10), an update step (PROC2) comprising: o for each software application of said subset: a step of determining (F20) a number of tokens intended for this software application; and a step of adding (F40) the number of tokens determined to the set of dedicated tokens associated with this software application within the limit of a maximum number of tokens fixed for this software application; and o if (F50), for at least one software application of the subset, the number of tokens determined is greater than the number of tokens added, and if there exists at least one other software application of the plurality of software applications which is associated with a set of tokens having a number of tokens lower than the maximum number of tokens set for this other software application, a step of reassigning (F60-F110) the number of residual tokens to said at least one other application. 2. Control method according to claim 1, in which the detected update event (F10) is an update instant for said subset among a plurality of update instants spaced regularly in the time. 3. The control method according to claim 1, in which the detected update event (F10) is the reception (E10) of a data packet intended to be processed by a said software application. 4. The control method according to claim 3, in which the updating step (PROC2) is implemented before the processing of said received data packet. 5. Control method according to any one of claims 1 to 4 wherein two steps of successive updates of the token sets are spaced by at least a predetermined time interval (G10). 6. Control method according to any one of claims 1 to 5 wherein during the determination step (F20), the number of tokens intended for the software application is determined from a token generation speed set for this software application. 7. The control method as claimed in claim 6, in which the same token generation speed is fixed for each of the software applications of said plurality of software applications. 8. Control method according to any one of claims 1 to 7 comprising, during the updating step: - an evaluation step (F30) of a global number of residual tokens for the subset of software applications; A step of identifying (F60), among said plurality of software applications, software applications associated with dedicated sets of tokens which after the adding step comprise numbers of tokens lower than the maximum numbers of tokens set for these software applications; and - a distribution step (F90) between the identified software applications of all or part of the overall number of residual tokens within the limit of the maximum number of tokens set for the identified software applications. 9. A control method according to claim 8 in which as long as at the end of the distribution step, there remain residual tokens and at least one software application associated with a set of tokens comprising a lower number of tokens at the maximum number of tokens fixed for this software application can be identified, said residual tokens are distributed between said at least one software application that can be identified. 10. Control method according to any one of claims 1 to 9 wherein the same maximum number of tokens is fixed for each of the software applications of said plurality of software applications. 11. Control method according to any one of claims 1 to 10 wherein during the processing step, said software application can access the resource until the completion of processing on said data packet. 12. Control method according to any one of claims 1 to 11 wherein said resource is a resource of a central processing unit of the computer system. 13. Computer program comprising instructions for the execution of the steps of the control method according to any one of claims 1 to 12 when said program is executed by a computer. 14. Recording medium readable by a computer on which a computer program is recorded comprising instructions for the execution of the steps of the control method according to any one of claims 1 to 12. 15. Control device (3) for access to a resource of a computer system by a plurality of software applications intended to run on the computer system, said control device comprising: - an association module (3A), configured to associate with each software application a dedicated set of tokens, each token representing a predetermined period of time of access to said resource; - modules, activated on receipt of a data packet intended to be processed by a said software application, and comprising: a processing module (3B) and a decrementation module (3C), activated if the set of tokens associated with said software application comprises at least one token, the processing module being configured to trigger the processing of the data packet by said software application using said resource, and the decrement module being configured to decrement the set of tokens associated with the software application by a number of tokens corresponding to a duration of access to said resource by the software application during processing the data packet; o a rejection module (3D) activated otherwise and configured to reject the data packet; and - an update module (3F) activated on detection of at least one predetermined update event relating to at least one subset of software applications of said plurality of software applications, this update module day including: o a determination module and an addition module, activated for each software application of the subset, the determination module being configured to determine a number of tokens intended for this software application, and the addition module being configured to add the number of tokens determined for the set of tokens associated with the software application within the limit of a maximum number of tokens fixed for this software application; and o a reassignment module, activated if for at least one software application of the subset of software applications, the number of tokens determined is greater than the number of tokens added, and if there is at least one other software application of the plurality of software applications which is associated with a set of tokens having a number of tokens lower than the maximum number of tokens set for this other software application, this reassignment module being configured to reassign the residual tokens to said at least one other application. 16. Computer system (1) comprising: - A plurality of software applications (APP1, ..., APPN) for processing data intended to run on the computer system and to access at least one resource of the computer system during their execution; and - a device (3) for controlling access to said at least one resource by the plurality of software applications according to claim 15.