FR3078462A1 - Procede et dispositif de controle d'un acces a une ressource d'un systeme informatique par des applications logicielles - Google Patents

Abstract

Le procédé de contrôle comprend : - l'association à chaque application logicielle (APP1-APPN) d'un ensemble de jetons (TB1-TBN), chaque jeton représentant un temps d'accès prédéterminé à la ressource ; - sur réception d'un paquet de données destiné à une application : ○ si l'ensemble de jetons de cette application comprend au moins un jeton, le traitement du paquet et la décrémentation de l'ensemble de jetons de l'application d'un nombre de jetons correspondant à la durée d'accès à la ressource par l'application lors du traitement ; ○ sinon, le rejet du paquet ; - sur détection d'un événement de mise à jour relatif à au moins un sous-ensemble d'applications : ○ pour chaque application du sous-ensemble, la détermination d'un nombre de jetons et l'ajout du nombre de jetons déterminé à l'ensemble de jetons de l'application dans la limite d'un nombre maximum ; ○ si, pour au moins une application du sous-ensemble, le nombre de jetons déterminé est supérieur au nombre de jetons ajouté, et s'il existe au moins une application dont l'ensemble de jetons a un nombre de jetons inférieur au nombre maximum fixé pour cette application, la réattribution du nombre de jetons résiduels à ladite au moins une application.

Description

Arrière-plan de l'invention

L'invention se rapporte au domaine général des systèmes informatiques et des réseaux de communication.

Elle concerne plus particulièrement le contrôle de l'accès à des ressources d'un système informatique et notamment à son unité centrale de traitement (ou CPU pour Central Processing Unit en anglais) par une pluralité d'applications logicielles s'exécutant sur ce système informatique. Par application logicielle on entend ici un programme ou un processus informatique apte à exécuter tout type de traitement.

On assiste aujourd'hui à une évolution dans la manière de construire et d'implémenter les réseaux de communication, afin notamment de faire face à la demande croissante de nouveaux services. En particulier, le récent paradigme de la virtualisation des fonctions réseaux (ou Network Function Virtualization (NFV) en anglais) propose d'implémenter des services réseaux sous forme d'applications logicielles (ou tout simplement de logiciels) s'exécutant sur des systèmes informatiques standards, non spécialisés. Pour atteindre les performances requises, l'architecture de ces applications logicielles doit être adaptée et optimisée pour le traitement des paquets de données échangés sur les réseaux (aussi couramment désignés par « paquets réseaux »).

Le traitement logiciel de paquets réseaux consiste à exécuter un ensemble d'opérations pour chaque paquet de données reçu, à la fois sur le paquet (comme par exemple la mise à jour ou l'ajout de champs au paquet de données) et/ou sur le système informatique sur lequel s'exécute le traitement logiciel (comme par exemple la mise à jour d'une structure de données) pour éventuellement envoyer le paquet de données vers un autre système informatique tel qu'une machine virtuelle ou un autre hôte. Pour exécuter ces opérations, deux approches sont généralement envisagées :

— selon une première approche, chaque opération du traitement logiciel à réaliser sur les paquets réseaux est exécutée par un processus différent. Lorsqu'un processus a achevé de réaliser l'opération qui lui est confiée sur un paquet réseau, il transmet ce paquet réseau au processus suivant en charge d'exécuter l'opération suivante sur le paquet ;

— selon une seconde approche, les paquets réseaux reçus sont répartis entre différents processus, chaque processus exécutant l'ensemble des opérations à réaliser sur les paquets qui lui sont attribués.

Cette seconde approche, couramment utilisée, est aussi connue sous l'appellation de modèle « run-to-completion » (ou d'exécution jusqu'à achèvement en français). En d'autres mots, chaque paquet réseau reçu par le processus auquel il est confié est traité complètement par celuici (i.e. toutes les opérations dont le processus est en charge sont exécutées par celui-ci sur le paquet réseau) avant de débuter le traitement d'un autre paquet réseau. Ce modèle permet d'éviter des transmissions coûteuses des paquets réseaux entre différents processus.

Pour tirer pleinement profit du modèle run-to-completion sur un système informatique ayant une unité centrale de traitement ou un processeur multi-cœur, il est préférable de dédier de façon propre à chaque processus, un ou plusieurs cœurs CPU du système informatique. Une telle configuration permet d'éviter de devoir gérer des changements de contexte (ou « context switch » en anglais) entre les différents cœurs CPU du système informatique. De tels changements de contexte sont particulièrement coûteux en temps CPU : toutes les informations relatives au processus considéré qui traduisent notamment son état (ex. drapeaux, registres, pointeurs d'instruction, etc., manipulés par le processus) doivent être sauvegardées pour pouvoir exécuter le processus sur un nouveau cœur CPU ; de même, les caches doivent être remis à zéro sur le nouveau cœur CPU.

En outre, il est courant d'avoir plusieurs processus ou plusieurs applications logicielles de traitement des paquets réseaux s'exécutant sur un même système informatique, en vue notamment d'utiliser de manière efficace les ressources de ce système informatique. Ces différentes applications logicielles peuvent éventuellement être rattachées à des entités différentes (par exemple à divers clients du système informatique).

Dans un tel contexte, se pose le problème du partage des ressources du système informatique (et notamment de son CPU ou de ses multiples cœurs CPU) entre les différentes applications logicielles qu'il héberge pour permettre leur exécution. Le modèle « run-tocompletion » complique quelque peu ce partage.

En effet, dans un modèle d'ordonnancement préemptif classique (ou « preemptive scheduling » en anglais), il est d'usage de répartir l'accès au(x) cœur(s) CPU du système informatique entre les différentes applications logicielles concernées en attribuant à celles-ci des unités de temps CPU pendant lesquelles les applications logicielles peuvent chacune accéder librement au(x) cœur(s) CPU. Si par exemple, n unités de temps CPU sont allouées à chaque application, n désignant un entier positif, toutes les n unités de temps, l'application en cours d'exécution sur le cœur CPU considéré est interrompue et remplacée par une autre application de manière à assurer un partage équitable du temps CPU entre les différentes applications. Toutefois, conformément au modèle « run-to-completion », l'exécution d'une application (i.e. le traitement d'un paquet réseau) ne peut être interrompue tant que l'ensemble des opérations prévues par cette application n'est pas achevé.

L'approche adoptée dans l'état actuel de la technique pour exécuter plusieurs applications logicielles selon un modèle « run-to-completion » sur un même système informatique hôte multi-cœur, tout en garantissant une répartition équitable des ressources du système informatique entre les différentes applications, consiste à allouer de façon dédiée à chacune des applications logicielles un ou plusieurs cœurs CPU. Cette approche présente cependant deux inconvénients majeurs.

Tout d'abord, elle requiert de dédier des ressources du système informatique au démultiplexage des paquets réseaux vers les différents cœurs CPU : ces ressources peuvent être constituées d'un ou de plusieurs cœurs CPU, ou la ou les carte(s) réseau du système informatique doiv(en)t être en mesure de réaliser elle(s)-même(s) ce démultiplexage.

En outre, cette approche ne permet pas une répartition très fine et par conséquent très efficace, des ressources du système informatique entre les différentes applications. Typiquement, deux applications logicielles ne peuvent pas partager un même cœur CPU où l'une d'entre elles se voit attribuer 1.5 cœur CPU tandis que l'autre disposerait de 2.5 cœurs CPU.

Objet et résumé de l'invention

L'invention permet de remédier notamment aux inconvénients de l'état de la technique en proposant un procédé de contrôle d'un accès à une ressource d'un système informatique par une pluralité d'applications logicielles destinées à s'exécuter sur le système informatique, ce procédé de contrôle comprenant :

— une étape d'association, à chaque application logicielle, d'un ensemble dédié de jetons, chaque jeton représentant une période de temps prédéterminée d'accès à ladite ressource ;

— sur réception d'un paquet de données destiné à être traité par une dite application logicielle :

o si l'ensemble de jetons associé à cette application logicielle comprend au moins un jeton :

une étape de traitement du paquet de données par l'application logicielle en utilisant la ressource ;

une étape de décrémentation de l'ensemble de jetons associé à l'application logicielle d'un nombre de jetons correspondant à une durée d'accès à ladite ressource par l'application logicielle pendant l'étape de traitement du paquet de données ;

o sinon, une étape de rejet du paquet de données ; et — sur détection d'au moins un événement de mise à jour relatif à au moins un sous-ensemble d'applications logicielles de la pluralité d'applications logicielles, une étape de mise à jour comprenant :

o pour chaque application logicielle dudit sous-ensemble :

une étape de détermination d'un nombre de jetons destiné à cette application logicielle ; et une étape d'ajout du nombre de jetons déterminé à l'ensemble de jetons dédié associé à cette application logicielle dans la limite d'un nombre maximum de jetons fixé pour cette application logicielle ; et o si, pour au moins une application logicielle du sous-ensemble d'applications logicielles, le nombre de jetons déterminé est supérieur au nombre de jetons ajouté, et s'il existe au moins une autre application logicielle de la pluralité d'applications logicielles qui est associée à un ensemble de jetons ayant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette autre application logicielle, une étape de réattribution des jetons résiduels à ladite au moins une autre application.

Corrélativement, l'invention propose aussi un dispositif de contrôle d'un accès à une ressource d'un système informatique par une pluralité d'applications logicielles destinées à s'exécuter sur le système informatique, chaque application logicielle étant associée à un ensemble dédié de jetons, chaque jeton représentant une période de temps prédéterminée d'accès à ladite ressource, ledit dispositif de contrôle comprenant :

— un module d'association, configuré pour associer à chaque application logicielle un ensemble dédié de jetons, chaque jeton représentant une période de temps prédéterminée d'accès à ladite ressource ;

— des modules, activés sur réception d'un paquet de données destiné à être traité par une dite application logicielle, et comprenant :

o un module de traitement et un module de décrémentation, activés si l'ensemble de jetons associé à cette application logicielle comprend au moins un jeton, le module de traitement étant configuré pour déclencher le traitement du paquet de données par l'application logicielle en utilisant la ressource, et le module de décrémentation étant configuré pour décrémenter l'ensemble de jetons associé à l'application logicielle d'un nombre de jetons correspondant à une durée d'accès à ladite ressource par l'application logicielle lors du traitement du paquet de données ;

o un module de rejet activé sinon et configuré pour rejeter le paquet de données ; et — un module de mise à jour activé sur détection d'au moins un événement de mise à jour relatif à au moins un sous-ensemble d'applications logicielles de la pluralité d'applications logicielles, ce module de mise à jour comprenant :

o un module de détermination et un module d'ajout, activés pour chaque application logicielle du sous-ensemble, le module de détermination étant configuré pour déterminer un nombre de jetons destiné à cette application logicielle, et le module d'ajout étant configuré pour ajouter le nombre de jetons déterminé à l'ensemble de jetons associé à l'application logicielle dans la limite d'un nombre maximum de jetons fixé pour cette application logicielle ; et o un module de réattribution, activé si pour au moins une application logicielle du sousensemble d'applications logicielles, le nombre de jetons déterminé est supérieur au nombre de jetons ajouté, et s'il existe au moins une autre application logicielle de la pluralité d'applications logicielles qui est associée à un ensemble de jetons ayant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette autre application logicielle, ce module de réattribution étant configuré pour réattribuer les jetons résiduels à ladite au moins une autre application.

Ainsi, l'invention propose un mécanisme permettant d'organiser le partage entre plusieurs applications logicielles de traitement de paquets de données, d'une ressource d'un système informatique, telle que par exemple une ressource de son unité de traitement centrale comme un cœur CPU, parfaitement compatible avec un modèle « run-to-completion » selon lequel, lorsqu'une application logicielle exécute un traitement sur un paquet de données en utilisant cette ressource, elle peut y accéder jusqu'à l'achèvement de ce traitement. Ce mécanisme, au lieu de s'employer à contrôler directement les temps d'accès à la ressource comme dans l'état de la technique, agit sur (i.e. limite) la quantité de données traitée par chaque application logicielle en utilisant la ressource. En fonction du choix des différents paramètres permettant d'agir sur cette quantité de données, l'invention conduit à un partage équitable des ressources entre les différentes applications logicielles, ou au contraire à favoriser lors de ce partage l'une ou l'autre des applications logicielles lors de ce partage. Le mécanisme proposé par l'invention est aisément configurable et offre une solution flexible pour le partage des ressources d'un système informatique.

A cet effet, l'invention s'appuie plus particulièrement sur un ensemble de jetons dédié alloué à chaque application logicielle, un jeton représentant une période de temps prédéterminée d'accès à la ressource considérée. Chaque ensemble de jetons dédiés peut comprendre un nombre maximum prédéterminé de jetons fixé pour l'application logicielle associée.

Les ensembles de jetons associés aux applications logicielles sont maintenus à jour en fonction de l'utilisation de la ressource par les applications logicielles. Plus précisément, chaque ensemble de jetons dédié à une application logicielle est décrémenté à chaque fois que l'application logicielle accède à la ressource pour traiter un paquet de données ; cette décrémentation est réalisée en fonction du temps passé par l'application logicielle pour effectuer le traitement complet du paquet qui lui a été confié (conformément au modèle « run-to-completion », l'application logicielle n'est pas interrompue tant qu'elle n'a pas achevé le traitement du paquet de données qui lui a été confié). Conformément à l'invention, il peut donc arriver qu'un ensemble de jetons associé à une application logicielle comprenne à un instant donné, suite à une décrémentation, un nombre de jetons négatif. Dans ce cas, il convient de noter que seuls les paquets destinés à cette application logicielle seront impactés, et ce, tant que de nouveaux jetons ne sont pas attribués à l'application logicielle.

En marge de cette décrémentation reflétant l'utilisation de la ressource par l'application logicielle, les ensembles de jetons associés aux applications logicielles sont mis à jour, et plus particulièrement incrémentés, sur détection d'un événement de mise à jour, et dans la limite d'un nombre maximum de jetons fixé pour chaque application logicielle. L'invention est remarquable en ce qu'elle réattribue tout ou partie des jetons résiduels qui en raison de cette limite ne sont pas ajoutés aux applications logicielles du sous-ensemble, à d'autres applications logicielles. Cela permet un partage de la ressource du système informatique entre les différentes applications logicielles hébergées par ce système informatique tout en tenant compte du modèle « run-to-completion » adopté pour l'ordonnancement des traitements mis en œuvre par ces applications.

Cette approche est au premier abord contre-intuitive, car elle peut conduire à rejeter certains paquets lorsque l'application logicielle à laquelle ils sont destinés ne dispose plus de jetons d'accès à la ressource, et ce, alors même que la ressource est peut-être disponible. Toutefois, elle permet une répartition plus efficace et plus précise de la ressource entre les applications logicielles que l'état de la technique lorsqu'un modèle « run-to-completion » est envisagé. Elle est d'ailleurs d'autant plus efficace que les temps d'exécution des traitements mis en œuvre par les applications logicielles sur les paquets de données sont courts.

L'invention est en outre très simple à mettre en œuvre : elle s'appuie en effet sur la provision et le maintien à jour d'un compteur de jetons (aussi appelé seau de jetons ou « token bucket » en anglais) dédié et unique pour chaque application logicielle, qui est incrémente et décrémenté en fonction de l'utilisation de la ressource par l'application logicielle et d'événements prédéterminés. Ces compteurs de jetons permettent de gérer finement la répartition de la ressource considérée entre des applications logicielles en concurrence pour utiliser cette ressource, en adaptant les paramètres de mise à jour des compteurs (ex. nombre maximum de jetons, vitesse de génération des nouveaux jetons ou nombre de nouveaux jetons générés pour chaque application, définition de la période d'accès prédéterminée, événements de mise à jour, etc.). Cette flexibilité et cette simplicité offrent la possibilité d'attribuer aisément à une application logicielle une fraction d'une ressource (par exemple un demi-cœur CPU) en termes de temps d'accès, et à une autre application logicielle une autre fraction de cette même ressource.

On note que l'utilisation de compteurs ou de seaux de jetons est connue pour limiter le nombre de paquets en entrée d'un système ou d'un nœud d'un réseau informatique, ou pour limiter le débit traversant ce système ou ce nœud. Les algorithmes dits du seau à jetons ou du seau percé s'appuient par exemple sur ces notions. L'invention est remarquable en ce qu'elle propose d'appliquer ce concept pour gérer l'accès à une ressource d'un système informatique en considérant des jetons qui correspondent à un temps d'accès à la ressource.

En outre, grâce au mécanisme mis en œuvre pour mettre à jour les ensembles de jetons associés aux applications logicielles et notamment à la réattribution des jetons résiduels, l'invention propose une approche dite « work-conserving » (ordonnancement sans oisiveté), consistant à toujours utiliser la ressource disponible dès lors qu'une application logicielle reçoit un paquet de données à traiter. En effet, par exemple, si un cœur CPU d'un processeur d'un système informatique est partagé entre deux programmes, que l'un des deux programmes a déjà atteint son quota de temps d'accès au cœur CPU (i.e. il a utilisé tous ses jetons) et qu'il reçoit encore des paquets à traiter, du temps d'accès au cœur CPU non utilisé par le deuxième programme peut lui être réattribué lors de la mise à jour des ensembles de jetons de façon à ne pas perdre de ressource CPU.

On note que l'exemple précédent est donné en référence à une ressource de type cœur CPU d'un processeur d'un système informatique. Toutefois l'invention s'applique pour contrôler l'accès à d'autres types de ressources comme par exemple pour contrôler l'accès à un disque dur d'un système informatique ou à une ressource réseau telle qu'une carte réseau par exemple, dès lors que l'accès à cette ressource peut être qualifié (caractérisé) en termes de temps d'accès.

Conformément à l'invention, de nouveaux jetons permettant d'accéder à la ressource sont générés pour les différentes applications logicielles sur détection d'événements prédéterminés.

Dans un mode de réalisation, l'événement de mise à jour détecté est un instant de mise à jour prédéterminé pour le sous-ensemble parmi une pluralité d'instants de mise à jour espacés de façon régulière dans le temps.

Cette mise à jour permet de réattribuer de façon périodique des jetons aux applications logicielles qui en consomment, et ce indépendamment de la réception des paquets de données.

On note que l'invention offre une grande flexibilité pour ce qui est de la définition du sous-ensemble concerné par chaque étape de mise à jour. On peut par exemple définir une pluralité de sous-ensembles contenant chacun une application logicielle différente : ceci revient à mettre à jour l'ensemble de jetons associés à chaque application logicielle à des instants différents. En variante, on peut définir un sous-ensemble contenant toutes les applications logicielles, ce qui revient à mettre à jour au même moment les ensembles de jetons des différentes applications logicielles considérées.

Ce mode de réalisation, dans lequel les étapes de mise à jour sont décorrélées de l'exécution des traitements sur les paquets de données, requiert la gestion de l'accès concurrent aux ensembles de jetons associés aux différentes applications logicielles. En effet, conformément à l'invention, on décrémente d'une part les ensembles de jetons après exécution des traitements et on les incrémente d'autre part, lors des étapes de mise à jour. Une synchronisation entre la génération des nouveaux jetons et leur utilisation par les applications logicielles pour accéder à la ressource est donc souhaitable. Cette synchronisation peut être réalisée de divers moyens, comme par exemple au moyen d'un verrou logiciel destiné à empêcher un accès simultané à un même ensemble de jetons d'une part pour l'incrémenter, et d'autre part, pour vérifier son contenu et le décrémenter lors du traitement d'un paquet de données.

La mise en œuvre d'une telle synchronisation peut se traduire par des latences, par exemple induites en raison du temps d'attente requis jusqu'à la libération du verrou avant de pouvoir démarrer un traitement.

Dans un autre mode de réalisation, l'événement de mise à jour détecté est la réception d'un paquet de données destiné à être traité par une dite application logicielle. Préférentiellement, l'étape de mise à jour est alors effectuée avant le traitement du paquet de données reçu par l'application logicielle.

Autrement dit dans ce mode de réalisation, la mise à jour des ensembles de jetons a lieu non plus à intervalles réguliers mais en fonction de la réception des paquets de données à traiter.

Dans un mode particulier de réalisation, on s'assure toutefois que deux étapes de mises à jour successives des ensembles de jetons sont espacées d'au moins un intervalle de temps prédéterminé, afin d'éviter une mise à jour trop fréquente des ensembles de jetons qui peut ellemême s'avérer consommatrice de ressources du système informatique.

Dans un mode particulier de réalisation, lors de l'étape de détermination, le nombre de jetons destiné à une application logicielle est déterminé à partir d'une vitesse de génération de jetons fixée pour cette application logicielle.

Le temps d'accès à la ressource par les applications logicielles pour traiter les paquets reçus est ainsi fonction de la vitesse de génération des jetons.

Une même vitesse de génération peut être notamment fixée pour chacune des applications logicielles de la pluralité d'applications logicielles, afin d'obtenir un partage équitable des ressources entre les différentes applications logicielles.

En variante, des vitesses de génération des jetons distinctes peuvent être considérées pour les différentes applications logicielles, par exemple en fonction de priorités que l'on souhaite attribuer à l'une ou l'autre des applications logicielles.

Dans un mode particulier de réalisation, le procédé de contrôle comprend lors de l'étape de mise à jour :

— une étape d'évaluation d'un nombre global de jetons résiduels pour le sous-ensemble d'applications logicielles ;

— une étape d'identification, parmi ladite pluralité d'applications logicielles, des applications logicielles associées à des ensembles dédiés de jetons qui après l'étape d'ajout comprennent des nombres de jetons inférieurs aux nombres maximaux de jetons fixés pour ces applications logicielles ; et — une étape de répartition entre les applications logicielles identifiées de tout ou partie du nombre global de jetons résiduels dans la limite des nombres maximums de jetons fixés pour les applications logicielles identifiées.

En outre, tant qu'à l'issue de l'étape de répartition, il reste des jetons résiduels et qu'au moins une application logicielle associée à un ensemble de jetons comprenant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette application logicielle peut être identifiée, ces jetons résiduels peuvent être répartis entre ladite au moins une application logicielle pouvant être identifiée.

Ce mode de réalisation favorise de façon simple et efficace un fonctionnement de type « work-conserving ». Tous les jetons résiduels sont réattribués entre les applications logicielles de sorte à pouvoir utiliser la ressource disponible lorsqu'elle est requise pour le traitement d'un paquet reçu par une application logicielle. Cela permet une répartition adaptée et précise de la ressource du système informatique en fonction des besoins des applications logicielles.

Dans un mode particulier de réalisation, un même nombre maximum de jetons est fixé pour chacune des applications logicielles de ladite pluralité d'applications logicielles.

Le nombre maximum de jetons fixé pour chaque application logicielle impacte l'exécution des applications logicielles et la stabilité du système informatique. Préférentiellement, on choisit ce nombre maximum de sorte à ne pas trop « hachurer » les exécutions des applications logicielles (on évite typiquement qu'une application consomme l'ensemble des jetons qui lui est dédié trop rapidement puis reste inactive pendant un temps long).

Un même nombre maximum de jetons fixé pour toutes les applications logicielles permet de faciliter l'implémentation de l'invention et notamment le dimensionnement de ses paramètres de fonctionnement.

Dans un mode particulier de réalisation, les différentes étapes du procédé de contrôle sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif de contrôle ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de contrôle tel que décrit ci-dessus.

Ce 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.

L'invention vise aussi un support d’informations ou d'enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné cidessus.

Le support d'informations ou d'enregistrement 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 ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur.

D’autre part, le support d'informations ou d'enregistrement 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 d’autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations ou d'enregistrement 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.

L'invention vise également un système informatique comprenant :

— une pluralité d'applications logicielles de traitement de données destinées à s'exécuter sur le système informatique et à accéder à au moins une ressource du système informatique lors de leurs exécutions ; et — un dispositif de contrôle d'un accès à ladite au moins une ressource par la pluralité d'applications logicielles conforme à l'invention.

On peut également envisager, dans d'autres modes de réalisation, que le procédé de contrôle, le dispositif de contrôle et le système informatique selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

— la figure 1 représente, de façon schématique, un système informatique et un dispositif de contrôle conformes à l'invention dans un mode particulier de réalisation ;

— les figures 2A et 2B représente, sous forme d'ordinogramme, un procédé de contrôle selon l'invention dans un premier mode de réalisation, lorsqu'il est mis en œuvre par le dispositif de contrôle de la figure 1 ; et — la figure 3 représente, sous forme d'ordinogramme, un procédé de contrôle selon l'invention dans un second mode de réalisation, lorsqu'il est mis en œuvre par le dispositif de contrôle de la figure 1.

Description détaillée de l'invention

La figure 1 représente, dans son environnement, un système informatique 1 conforme à l'invention, dans un mode particulier de réalisation.

Dans l'exemple illustré à la figure 1, le système informatique 1 est un ordinateur, équipé d'un processeur 2 (ou unité centrale de traitement) mono ou multi-cœur : il comprend K cœurs CPU notés CPU1, CPU2,...,CPUK, K désignant un entier supérieur ou égal à 1. Le système informatique 1 héberge dans cet exemple une pluralité d'applications logicielles (i.e. de programmes informatiques) APP1, APP2,..., APPN, N désignant un entier supérieur à 1, aptes à appliquer divers traitements sur des paquets de données, et à utiliser le processeur 2 du système informatique 1 pour exécuter ces traitements. Chacun des traitements réalisés peut comprendre une ou plusieurs opérations. On se place ici, à titre illustratif, dans un contexte de virtualisation de fonctions réseaux (NFV) tel que mentionné précédemment, et on suppose que les traitements mis en œuvre par les applications logicielles APP1, APP2,..., APPN, sont des traitements destinés à être appliqués sur des paquets de données réseaux (i.e. échangés au sein d'un réseau de communication). De tels traitements consistent par exemple à modifier/ajouter ou supprimer un entête d'un paquet, à vérifier la légitimité d'un paquet en fonction de règles de contrôle d'accès, à agréger des statistiques à partir des paquets (pour mettre en œuvre par exemple une fonction de supervision), etc.

Cet exemple n'est toutefois envisagé qu'à titre illustratif et l'invention peut s'appliquer dans d'autres contextes, à d'autres types de traitements et/ou de paquets de données, etc. Le système informatique 1 peut également comprendre en variante une pluralité d'ordinateurs ou d'autres éléments matériels, qui peuvent être reliés entre eux par exemple via un réseau de télécommunications (filaire ou sans fil).

Conformément à l'invention, le système informatique 1 comprend un dispositif de contrôle 3 de l'accès par les applications logicielles APP1,...,APPN hébergées par le système informatique 1 aux ressources du système informatique 1, et plus particulièrement ici, à son processeur 2 et à son ou ses cœurs CPU, CPU1,...,CPUK, Chaque cœur CPU constitue ici une ressource du système informatique 1 au sens de l'invention. On note que l'invention peut également s'appliquer à d'autres ressources du système informatique 1, comme par exemple à un disque dur, ou à des ressources réseaux (ex. carte réseau), etc., dès lors qu'il est possible de qualifier ou de caractériser l'accès à ces ressources en termes de temps d'accès.

Le dispositif de contrôle 3 est configuré ici pour appliquer un modèle « run-tocompletion » pour l'ordonnancement des différents traitements réalisés par les applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ sur les paquets de données réseaux qui sont confiés au système informatique 1, et gérer l'accès au processeur 2 pour exécuter ces traitements. Dans le mode de réalisation décrit ici, on suppose qu'un unique cœur CPU du processeur 2 du système informatique 1, à savoir le cœur CPU1, est dédié à l'exécution des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ. Si plusieurs cœurs CPU sont dédiés aux applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ, pour l'exécution de leurs traitements, l'accès à chacun de ces cœurs CPU est géré par le dispositif de contrôle 3 de la même façon que ce qui est décrit par la suite pour le cœur CPU1.

Selon le modèle « run-to-completion », chaque application logicielle APPn, n=l,...,N, lorsqu'elle reçoit un paquet de données qui lui est destiné pour traitement, réalise l'ensemble des opérations prévues par ce traitement sur ce paquet en utilisant le cœur CPU1 sans être interrompue par le dispositif de contrôle 3 : en d'autres mots, l'accès au cœur CPU1 du processeur 2 lui est assuré jusqu'à l'achèvement du traitement qu'elle exécute sur le paquet de données.

On note que l'invention s'applique quelle que soit la quantité de ressource CPU du cœur CPU1 du processeur 2 attribuée à proprement parler aux applications ΑΡΡΙ,.,.,ΑΡΡΝ pour exécuter leurs traitements. On suppose ici par souci de simplification que les applications ΑΡΡΙ,.,.,ΑΡΡΝ sont en mesure d'utiliser tout le temps d'accès au cœur CPU1 du processeur 2, et que le dispositif de contrôle 3 permet de contrôler cet accès concurrent par les applications ΑΡΡΙ,.,.,ΑΡΡΝ à cette ressource CPU.

En variante, seule une fraction du temps d'accès possible au cœur CPU1 peut être attribuée aux applications ΑΡΡΙ,.,.,ΑΡΡΝ (par exemple 75%), la fraction restante pouvant être dédiée à d'autres applications ou processus gérés par le système informatique 1. La façon dont cet ajustement peut être réalisé est décrit plus en détails ultérieurement. Dans la suite de la description, par souci de simplicité, il est fait référence de manière générale à « la ressource CPU » pour désigner la partie du cœur CPU1 dédiée aux applications APP1,...,APPN pour l'exécution de leurs traitements.

Conformément à l'invention, pour contrôler l'accès au cœur CPU1 du processeur 2, le dispositif de contrôle 3 associe, via un module d'association 3A prévu à cet effet, à chaque application logicielle APP1,...,APPN hébergée par le système informatique 1 un ensemble (aussi appelé seau dans la suite de la description) dédié de jetons d'accès au processeur 2. Chaque jeton représente une période prédéterminée T de temps d'accès à la ressource CPU1 ; cette période de temps T définit dans le contexte de l'invention une « unité de temps CPU » (ou une unité de temps d'accès à la ressource CPU1) allouée aux applications, telle que par exemple une nanoseconde de temps CPU, le temps CPU désignant ici la durée pendant laquelle la ressource CPU considérée (i.e. le cœur CPU1 ici) est active, c'est-à-dire le temps pendant lequel on peut y accéder. Ce temps CPU ne comptabilise pas typiquement les interruptions de l'accès au cœur CPU1 : une nanoseconde de temps CPU peut ainsi en soi être distincte d'une nanoseconde. La quantité de jetons attribuée à chaque application logicielle ΑΡΡΙ,.,.,ΑΡΡΝ est décrite plus en détail ultérieurement.

Chaque seau de jetons noté TBn, n=l,...,N associé à une application logicielle APPn peut contenir un nombre maximum de jetons Bn. Par souci de simplification, on suppose ici que le même nombre maximum de jetons B est fixé pour toutes les applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ, soit B1=B2=...=BN= B. Le nombre maximum B peut être choisi de façon expérimentale, comme décrit plus en détail ultérieurement.

En variante, des nombres Bn, n=l,...,N différents peuvent être envisagés.

Le dispositif de contrôle 3 manipule les différents seaux de jetons TBn, n=l,...,N pour contrôler l'accès à la ressource CPU considérée du système informatique 1 (le cœur CPU1 dans l'exemple envisagé ici). A cet effet, il comprend une pluralité de modules fonctionnels s'appuyant ou commandant divers moyens matériels du système informatique 1 (par exemple une mémoire vive, une mémoire morte, une mémoire non volatile, des moyens de communication, etc, dont est pourvu classiquement un système informatique et ici le système informatique 1) et mettant en œuvre le procédé de contrôle selon l'invention. Ces modules fonctionnels sont ici des modules logiciels définis par des instructions d'un programme d'ordinateur PROG conforme à l'invention. Le programme d'ordinateur PROG est stocké dans une mémoire morte 4 du système informatique 1 lisible par le processeur 2. Il comporte des instructions pour l'exécution des étapes du procédé de contrôle selon l'invention mis en œuvre par le dispositif de contrôle 3. La mémoire morte 4 constitue ainsi un support d'enregistrement conforme à l'invention, sur lequel est enregistré le programme d'ordinateur PROG.

Le programme d'ordinateur PROG définit les modules fonctionnels suivants du dispositif de contrôle 3 :

— un module d'association 3A déjà mentionné, configuré pour associer à chacune des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ les seaux de jetons ΤΒΙ,.,.,ΤΒΝ respectivement ;

— des modules, activés sur réception par le dispositif de contrôle 3 du système informatique 1, d'un paquet de données destiné à être traité par l'une des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ (notée APPj dans la suite) et comprenant :

o un module 3B d'inspection de l'ensemble, ou du seau, de jetons TBj associé à l'application logicielle APPj ;

o un module 3C de traitement et un module 3D de décrémentation, activés si le module d'inspection 3B détermine que le seau de jetons TBj comprend au moins un jeton. Le module de traitement 3C est configuré pour déclencher le traitement du paquet de données par l'application logicielle APPj si le seau de jetons TBj comprend au moins un jeton. Le module de décrémentation 3D est configuré pour décrémenter le seau de jetons TBj d'un nombre de jetons correspondant à la durée du traitement effectué par l'application logicielle APPj sur le paquet de données (cette durée caractérise le temps d'accès à la ressource CPU1 par l'application logicielle APPj pour le traitement du paquet de données) ;

o un module 3E de rejet activé si le module 3A d'inspection détermine que le seau TBj ne contient pas au moins un jeton, et configuré pour rejeter le paquet de données ; et — un module 3F de mise à jour, activé à chaque détection d'un événement de mise à jour relatif à un ou plusieurs sous-ensembles SI,...,SL d'applications logicielles de la pluralité d'applications logicielles, L désignant un entier supérieur ou égal à 1. Aucune limitation n'est attachée à la façon dont on définit les sous-ensembles. Les sous-ensembles S1,...,SL sont disjoints (i.e. ils ne comprennent pas d'application(s) logicielle(s) en commun). A titre illustratif, L peut être pris égal à 1 et le sous-ensemble SI contenir l'ensemble des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ. Selon un autre exemple, on peut considérer L=N sous-ensembles chacun constitué d'une unique application logicielle distincte. On désigne par N(S) le nombre d'applications logicielles compris dans chaque sous-ensemble S, S=S1,...,SL, et par I(S) l'ensemble des indices des applications logicielles de la pluralité d'applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ compris dans ce sous-ensemble S. Conformément à l'invention, le module 3F de mise à jour comprend :

o un module de détermination 3F1 et un module d'ajout 3F2, activés pour chaque application logicielle APPi, iel(S) du sous-ensemble S considéré, le module de détermination 3F1 étant configuré pour déterminer un nombre de jetons ri destiné à cette application logicielle APPi, et le module d'ajout 3F2 étant configuré pour ajouter le nombre de jetons déterminé ri au seau de jetons dédié TBi associé à l'application logicielle APPi dans la limite du nombre maximum Bi (=B ici) de jetons fixé pour cette application logicielle ; et o un module de réattribution 3F3, activé si pour au moins une application logicielle notée APPm du sous-ensemble S, le nombre de jetons rm déterminé par le module de détermination 3F1 est supérieur au nombre de jetons ajouté par le module d'ajout 3F2 au seau de jetons TBm (ce nombre de jetons ajouté est en fait égal à min(Bm-bm,rm) où bm désigne le nombre de jetons déjà présents lors de la mise à jour dans le seau de jetons TBm, bm pouvant être positif, négatif ou nul). Le module de réattribution 3F3 est configuré pour réattribuer les jetons résiduels (autrement dit, les rm-min(Bmbm,rm) jetons résiduels pour chaque application APPm concernée) à au moins une autre application de ladite pluralité d'applications logicielles ΑΡΡΙ,.,.ΑΡΡΝ.

Les fonctions de ces modules sont décrites plus en détail maintenant, en référence aux étapes du procédé de contrôle selon l'invention.

Conformément à l'invention, le procédé de contrôle s'appuie sur deux processus :

— un premier processus PROC1 qui vise à proprement parler à gérer un paquet de données entrant PKT destiné à l'une des applications logicielles APP1,...,APPN. Ce processus PROC1 vise plus particulièrement à identifier l'application logicielle à laquelle est destiné le paquet PKT, à déterminer si elle est, au vu de l'état courant de son seau de jetons, en mesure de traiter ce paquet, et le cas échéant, à mettre à jour (plus précisément à décrémenter dans le cas du processus PROC1) le nombre de jetons contenu dans le seau de l'application logicielle en fonction du temps d'accès à la ressource CPU1 consommé par l'application logicielle pour le traitement du paquet ; et — un second processus PROC2 qui vise à mettre à jour, sur détection d'événements de mise à jour, les seaux de jetons associés aux applications logicielles APP1,...,APPN et plus précisément à incrémenter les nombres de jetons contenus dans ces seaux dans la limite des nombres maximums fixés pour ceux-ci.

Autrement dit, le procédé de contrôle met en œuvre deux types de mises à jour des seaux de jetons associés aux applications logicielles : une décrémentation du nombre de jetons contenus dans le seau lorsque l'application logicielle a consommé de la ressource pour traiter un paquet de données, et une incrémentation du nombre de jetons sur détection d'événements prédéterminés.

Nous allons maintenant décrire plus en détail chacun des processus PROC1 et PROC2 dans plusieurs modes de réalisation de l'invention.

Dans un premier mode de réalisation, représenté sur les figures 2A et 2B, les deux processus sont mis en œuvre indépendamment l'un de l'autre.

Plus précisément, dans le premier mode de réalisation, le processus PROC1 (illustré sur la figure 2A) est mis en œuvre par le dispositif de contrôle 3 sur réception d'un paquet de données PKT à traiter, tandis que le processus PROC2 (illustré sur la figure 2B) est mis en œuvre à des instants de mise à jour prédéterminés, fixés pour chaque sous-ensemble S1,...,SL. L'événement déclenchant la mise à jour opérée par le processus PROC2 (incrémentation des seaux de jetons) est donc ici la détection d'un instant de mise à jour prédéterminé, fixé pour chaque sous-ensemble SI,...,SL. On réalise ici, pour chaque sous-ensemble SI, 1=1,...,L, une mise à jour selon le processus PROC2 à des instants de mise à jour espacés de façon régulière dans le temps.

La figure 2A illustre les étapes du processus PROC1.

Lorsqu'un paquet de données PKT à traiter est reçu par le dispositif de contrôle 3 (étape E10), le dispositif de contrôle 3 détermine dans un premier temps à quelle application logicielle parmi les applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ ce paquet PKT est destiné (étape E20). A cet effet, le dispositif de contrôle 3 examine par exemple les valeurs d'un ou de plusieurs entêtes du paquet PKT et utilise des associations (valeur(s), application) pour déterminer l'application logicielle destinataire de ce paquet.

On suppose ici que le paquet de données PKT est destiné à l'application logicielle APPn. Puis le dispositif de contrôle 3, par l'intermédiaire de son module d'inspection 3B, détermine si le seau TBn de jetons associé à l'application logicielle APPn comprend au moins un jeton, autrement si bn (nombre de jetons compris dans le seau TBn à l'instant courant) est supérieur ou égal à 1 (étape test E30).

Si le seau TBn ne contient pas au moins un jeton (réponse non à l'étape E30), i.e. le nombre de jetons bn est négatif ou nul, le paquet PKT est rejeté par le module de rejet 3E du dispositif de contrôle 3 (étape E40). Il est par exemple supprimé par le module de rejet 3E. En d'autres mots, il n'est pas traité.

Si le seau TBn contient au moins un jeton (réponse oui à l'étape test E30), le module de traitement 3C du dispositif de contrôle 3 le transmet à l'application logicielle APPn et déclenche le traitement du paquet PKT par l'application logicielle APPn (étape E50). L'application logicielle APPn a accès librement à la ressource CPU1 et peut exécuter sans être interrompue les diverses opérations du traitement qu'elle doit appliquer sur le paquet PKT. La durée notée tf-td pendant laquelle la ressource CPU1 est utilisée par l'application logicielle APPn lors du traitement du paquet PKT est mesurée par la ressource CPU1. Cette durée caractérise la durée d'accès à la ressource CPU1 par l'application logicielle lors du traitement du paquet PKT.

A l'issue du traitement du paquet PKT par l'application logicielle APPn, le seau à jetons TBn de l'application APPn est mis à jour (étape E60).

Plus spécifiquement, le nombre de jetons bn contenu dans le seau TBn est décrémenté par le module de décrémentation 3D du dispositif de contrôle 3 d'un nombre de jetons noté ici dn. Ce nombre de jetons dn correspond à la durée d'accès à la ressource CPU1 par l'application logicielle APPn lors du traitement du paquet de données PKT, soit à tf-td. Cette durée caractérise la durée pendant laquelle l'application logicielle APPn a pu accéder librement à la ressource CPU1 pour traiter le paquet de données PKT lors de l'étape de traitement E50 sans être interrompue par une autre application. Elle est quantifiée ici par le module de décrémentation 3D en unités de temps CPU (de durée T chacune) : dans l'exemple envisagé ici, le module de décrémentation 3C estime cette durée d'accès à dn.T, chaque jeton correspondant à une unité de temps CPU (de durée T) comme indiqué précédemment. On note qu'il est possible que dn.T ne soit pas exactement égal à tf-td en fonction des valeurs de dn et de T, dn étant un nombre entier (on a (dn-l).T <tf-td< dn.T).

Cette étape de décrémentation E60 clôture le processus PROC1. Le dispositif de contrôle 3 se met alors en attente de la réception d'un nouveau paquet à traiter. Les étapes du processus PROC1 sont répétées pour chaque nouveau paquet de données reçu par le dispositif de contrôle 3 et destiné à une application logicielle ΑΡΡΙ,,.,,ΑΡΡΝ.

Comme mentionné précédemment, dans le premier mode de réalisation, le dispositif de contrôle 3 met en œuvre, en marge (c'est-à-dire indépendamment) de la réception des paquets de données à traiter (autrement dit, en marge du processus PROC1), le processus PROC2 visant à générer de nouveaux jetons d'accès à la ressource CPU1 pour les applications logicielles ΑΡΡΙ,,.,,ΑΡΡΝ. Ce processus PROC2 est illustré sur la figure 2B et est mis en œuvre pour chaque sous-ensemble SI,,..,SL dès que les instants de mise à jour de ces sous-ensembles sont détectés (étape F10). Les instants de mise à jour des sous-ensembles S1,...,SL sont espacés de façon régulière dans le temps. On note ûtl l'intervalle de temps séparant deux mises à jour selon le processus PROC2 pour le sous-ensemble SI, 1=1,...,L. Un même intervalle de temps Atl peut être choisi pour tous les sous-ensembles SI ou des intervalles de temps différents. De même, les mises à jour des différents sous-ensembles peuvent être désynchronisées les unes par rapport aux autres (i.e. effectuées à des instants tOI+Atl avec tOI différents selon les sous-ensembles SI).

Dans la suite de la description, on considère qu'un instant de mise à jour relatif au sous-ensemble d'applications logicielles S (S étant l'un des sous-ensembles S1,...,SL mentionné cidessus) est détecté lors de l'étape F10 (évènement de mise à jour au sens de l'invention). On désigne par I(S) l'ensemble des indices des applications logicielles appartenant au sous-ensemble S et par AtS l'intervalle de temps séparant deux mises à jour pour le sous-ensemble S.

De nouveaux jetons d'accès sont alors générés par le dispositif de contrôle 3 pour les applications logicielles APPi, iel(S), via son module de mise à jour 3F. La génération à proprement parler de nouveaux jetons conformément au processus PROC2 se déroule en trois étapes F20 à F40.

Lors de cette génération, pour chaque application logicielle APPi, iel(S), le dispositif de contrôle 3, via son module de détermination 3F1, détermine tout d'abord un nombre de jetons ri destiné à l'application logicielle APPi, et plus particulièrement, à être ajouté à son seau de jetons TBi (i.e. aux bi jetons déjà présents dans le seau de jetons TBi, bi désignant le nombre courant de jetons présents dans le seau TBi) (étape F20). Dans le mode de réalisation décrit ici, le nombre de jetons ri est déterminé à partir d'une vitesse de génération de jetons fixée pour l'application logicielle APPi. On note vi cette vitesse ; elle est exprimée en jetons par seconde, autrement dit ici en unités de temps CPU par seconde.

Une même vitesse de génération de jetons v pour toutes les applications logicielles ΑΡΡΙ,,.,,ΑΡΡΝ peut être envisagée. En variante, on peut envisager des vitesses de génération distinctes en fonction des applications logicielles APPi, i=l,...,N. La somme des vitesses de génération détermine le pourcentage du temps d'accès à la ressource CPU1 que l'opérateur du système informatique 1 est prêt à allouer aux applications logicielles APPi, i=1,...,N.

Ainsi, par exemple, si chaque jeton représente une nanoseconde de temps CPU (i.e. du temps d'accès à la ressource CPU1 ici), cela signifie que le dispositif de contrôle 3 dispose de 10⁹ jetons à allouer entre les applications logicielles APP1,...,APPN si le cœur CPU1 est dédié entièrement à ces applications. Il peut en variante être décidé par l'opérateur du système informatique 1 de n'allouer qu'une fraction des 10⁹ jetons aux applications logicielles APP1,...,APPN (par exemple 80%). Si on désigne par a la fraction du temps CPU dédié par l'opérateur aux applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ et NbT le nombre de jetons disponibles chaque seconde, la somme des vitesses vi de génération des jetons, i=l,...N, vérifie la relation :

N = a. NbT i=l

Ainsi, si une même vitesse de génération vi=v, i=l,...,N est fixée pour toutes les applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ, les jetons sont répartis de façon équitable entre les applications.

L'opérateur du système informatique 1 peut en variante décider de prioriser certaines applications logicielles APPi en leur attribuant des vitesses de génération de jetons supérieures aux autres applications.

A partir de la vitesse de génération vi, le module de détermination 3F1 détermine le nombre de jetons à générer ri de la façon suivante :

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

Parmi les nouveaux jetons générés, en raison des nombres maximums de jetons fixés pour chaque seau de jetons et de l'état courant des seaux de jetons des applications logicielles APPi, iel(S), certains jetons ne pourront sans doute pas être effectivement alloués aux applications auxquelles ils étaient initialement destinés. Ces jetons sont dits résiduels. Le dispositif de contrôle 3 évalue, via son module de réattribution 3F3, le nombre global de ces jetons résiduels s'il en existe (étape F30) pour l'ensemble des applications logicielles de l'ensemble I(S). Ce nombre global de jetons résiduels, noté r', est évalué par le module de réattribution 3F3 de la façon suivante :

r' = (ri - min(B - bi,ri)) ie!(S) où bi désigne le nombre de jetons courant dans le seau TBi de l'application logicielle APPi comme mentionné précédemment.

Puis le dispositif de contrôle 3 ajoute, par le biais de son module d'ajout 3F2, à chaque seau TBi associé à chaque application logicielle APPi de l'ensemble I(S), le nombre de jetons ri déterminé pour cette application logicielle APPi dans la limite du nombre maximum de jetons Bi défini pour celle-ci (étape F40) : le module d'ajout 3F2 ajoute ainsi à chaque seau TBi de jetons associé à une application logicielle APPi, iel(S), mîn(Bi-bi,ri) jetons (soit min(B-bi,ri) dans l'exemple envisagé ici où Bi=B). A l'issue de cette étape, chaque seau de jetons TBi, iel(S) contient donc un nombre de jetons égal à min(B,bi+ri) : il s'agit du nouveau nombre courant bi de jetons contenu dans le seau TBi de l'application logicielle APPi, iel(S).

Si le nombre ri de jetons résiduels évalués à l'étape F30 est nul (réponse non à l'étape test F50), le processus PROC2 de mise à jour s'achève (étape F120).

Conformément à l'invention, si au contraire le nombre global ri de jetons résiduels évalué à l'étape F30 par le dispositif de contrôle 3 est supérieur à 0 (réponse oui à l'étape test F50), les jetons résiduels qui n'ont pas pu être ajoutés aux seaux des applications logicielles ayant atteint leur nombre maximum de jetons sont réattribués par le module de réattribution 3F3 aux autres applications logicielles, ou tout du moins à celles qui n'ont pas encore atteint leur nombre maximum de jetons, et ce, dans la limite de ce nombre maximum de jetons.

Dans le mode de réalisation décrit ici, on considère pour la réattribution des jetons résiduels toutes les applications logicielles APP1,...,APPN qui n'ont pas atteint leur nombre maximum de jetons. Le module de réattribution 3F3 identifie donc dans un premier temps les applications logicielles APPj parmi les applications ΑΡΡΙ,,.,,ΑΡΡΝ pour lesquelles, à l'issue de l'étape F40, le nombre bj courant de jetons présent dans leur seau TBj est inférieur au nombre maximum de jetons Bj=B fixé pour ces applications (étape F60). On désigne par J l'ensemble des indices des applications logicielles vérifiant cette condition.

Puis, le module de réattribution 3F3 répartit entre les applications logicielles ainsi identifiées tout ou partie du nombre global ri de jetons résiduels évalué dans la limite des nombres maximaux de jetons fixés pour les applications logicielles identifiées dans l'ensemble J. Plus précisément ici, il réattribue les ri jetons résiduels aux applications logicielles identifiées dans l'ensemble J en fonction de leurs vitesses de génération respectives (i.e. au prorata de ces vitesses). A cet effet, il détermine, pour chacune des applications logicielles APPj, jeJ, un nombre de jetons rj destiné à cette application en appliquant la relation suivante (étape F70) :

Comme lors de l'étape F30, parmi les jetons résiduels ri, en raison des nombres maximums de jetons fixés pour les seaux de jetons des applications logicielles identifiées dans l'ensemble J et de l'état courant de ces seaux, il se peut que certains jetons ne puissent pas être alloués aux applications auxquelles on les a destinés lors de l'étape F70 (autrement dit que pour certaines applications logicielles de l'ensemble J, seulement une partie des rj jetons destinés à ces applications puisse être ajoutés à leurs seaux respectifs). Le module de réattribution 3F3 réévalue ainsi le nombre global ri des jetons résiduels au moyen de la relation suivante (étape F80) :

Puis le module d'ajout 3F2 ajoute, à chaque seau TBj dédié à chaque application logicielle APPj, jeJ, le nombre de jetons rj déterminé lors de l'étape F70 pour cette application logicielle APPj dans la limite du nombre maximum de jetons Bj défini pour celle-ci (étape F90) : en d'autres mots, il ajoute à chaque seau TBj de jetons associé à une application logicielle APPj de l'ensemble J, min(Bi-bj,rj) jetons (soit min(B-bj,rj dans l'exemple envisagé ici où Bj=B pour j=l,...,N).

A l'issue de cette étape F90, chaque seau de jetons TBj associé à une application logicielle APPj contient donc un nombre courant de jetons égal à min(B,bj+rj) : ce nombre constitue le nouveau nombre courant de jetons bj contenus dans le seau TBj, jeJ.

Le module de réattribution 3F3 vérifie s'il reste des jetons résiduels à réattribuer entre les applications logicielles, autrement dit si r' est supérieur à 0 (étape test F100).

Si r' est nul (réponse non à l'étape test F100), la mise à jour réalisée par le processus PROC2 est achevée (étape F120).

S'il reste encore des jetons à réattribuer (i.e. r'>0, réponse oui à l'étape test F100), le module de réattribution 3F3 vérifie s'il existe au moins une application logicielle APPjO parmi les applications identifiées dans l'ensemble J disposant d'un seau de jetons contenant un nombre de jetons courant bjO inférieur au nombre maximum de jetons maximum BjO fixé pour cette application logicielle (étape test F110).

S'il n'existe pas d'application vérifiant cette condition (réponse non à l'étape test F110), la mise à jour réalisée par le processus PROC2 s'achève (étape F120).

S'il existe au moins une application vérifiant cette condition (réponse oui à l'étape test Fl 10), alors les étapes d'identification F60, de détermination F70, de réévaluation F80, d'ajout F90 et de test F100 sont réitérées pour ladite au moins une application, jusqu'à ce que le nombre de jetons résiduels r' soit nul ou que tous les seaux associés respectivement aux applications logicielles APP1,...APPN aient atteint leurs nombres de jetons maximum (réponses non aux étapes tests F90 et F100). Ceci clôture la mise à jour réalisée par le processus PROC2 (étape F120).

On note que pour permettre aux processus PROC1 et PROC2 de s'exécuter en parallèle de façon indépendante l'une de l'autre, on peut envisager d'utiliser des verrous logiciels permettant par exemple, lorsque le processus PROC1 d'empêcher l'accès aux seaux des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ par le processus PROC2 et inversement, de sorte à éviter un accès concurrent aux seaux par les deux processus. L'usage de tels verrous logiciels est connu en soi et n'est pas décrit en détail ici.

En variante, on peut envisager de synchroniser l'exécution d'un processus par rapport à l'autre, de sorte à éviter que ces deux processus s'exécutent en même temps et procèdent à une mise à jour concurrente des seaux de jetons des applications logicielles APP1,....,APPN.

La figure 3 représente un deuxième mode de réalisation de l'invention dans lequel le processus PROC2 et la génération de nouveaux jetons pour les applications logicielles ΑΡΡΙ,,.,.,ΑΡΡΝ sont réalisés à des intervalles irréguliers, et ne nécessite pas de gérer un accès simultané aux seaux des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ par les deux processus PROC1 et

PROC2.

Dans ce deuxième mode de réalisation, l'événement déclencheur (étape F10) de la mise à jour réalisée au moyen du processus PROC2 est la réception par le dispositif de contrôle 3 d'un paquet de données PKT destiné à être traité par l'une (au moins) des applications logicielles APP1,...APPN (étape E10 décrite précédemment en référence à la figure 2A). Le dispositif de contrôle 3 vérifie en outre si la dernière mise à jour date de plus d'un intervalle de temps Δ prédéterminé (étape test G10), afin de s'assurer que deux mises à jour successives des seaux de jetons des applications APP1,...,APPN sont espacées d'au moins l'intervalle de temps Δ.

Si tel est le cas (réponse oui à l'étape test G10), le dispositif de contrôle 3 déclenche la mise à jour des seaux de jetons selon le processus PROC2 (étape G20), de façon identique à ce qui a été décrit pour le premier mode de réalisation en référence à la figure 2B. Il peut lors de cette mise à jour considérer un sous-ensemble S d'applications logicielles préalablement sélectionné parmi une pluralité de sous-ensembles SI,...SL, chaque sous-ensemble SI, 1=1,...,L comprenant une ou plusieurs applications logicielles parmi les applications APP1,...,APPN, les sous-ensembles S1,...,SL étant disjoints comme dans le premier mode de réalisation : dans ce cas, le sousensemble S sélectionné est le sous-ensemble parmi les sous-ensembles S1,...,SL qui comprend l'application logicielle APPn à laquelle le paquet PKT est destiné. En variante, lors de la mise à jour selon le processus PROC2, le dispositif de contrôle 3 peut considérer l'ensemble des applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ (i.e. le sous-ensemble S comprend ici toutes les applications logicielles APP1,...,APPN). Le processus PROC2 est appliqué en considérant Atl = AtUPD_s, où AtUPD_s désigne l'intervalle de temps séparant cette mise à jour de la dernière mise à jour effectuée par le dispositif de contrôle 3 selon le processus PROC2 pour le sous-ensemble S.

Sinon (réponse non à l'étape test G10), le dispositif de contrôle 3 exécute directement le processus PROC1 de traitement du paquet de données PKT reçu à l'étape E10 (étape G30) et aucune mise à jour selon le processus PROC2 n'est effectuée.

A l'issue de la mise à jour réalisée le cas échéant lors de l'étape G20, le dispositif de contrôle 3 déclenche le traitement du paquet PKT via le processus PROC1 (étape G30), comme décrit précédemment dans le premier mode de réalisation en référence à la figure 2A.

On note que quel que soit le mode de réalisation envisagé, le processus PROC2 peut être mis en œuvre lors d'une étape d'initialisation des seaux de jetons associés aux différentes applications logicielles ΑΡΡΙ,.,.,ΑΡΡΝ pour attribuer des jetons à ces différentes applications avant même la réception d'un paquet de données. En variante, on peut envisager d'attribuer, lors de cette étape d'initialisation, à chaque application logicielle ΑΡΡΙ,.,.,ΑΡΡΝ un même nombre de jetons prédéterminé ou un nombre de jetons différents (égal par exemple aux nombres maximums de jetons ΒΙ,.,,.,ΒΝ).

Claims (16)

1. REVENDICATIONS

   1. Procédé de contrôle d'un accès à une ressource (CPU1) d'un système informatique (1) par une pluralité d'applications logicielles (ΑΡΡΙ,.,.ΑΡΡΝ) destinées à s'exécuter sur le système informatique, le procédé de contrôle comprenant :

   — une étape d'association, à chaque application logicielle, d'un ensemble dédié de jetons (ΤΒΙ,.,.,ΤΒΝ), chaque jeton représentant une période de temps prédéterminée d'accès à ladite ressource ;

   — sur réception (E10) d'un paquet de données (PKT) destiné à être traité par une dite application logicielle :

   o si l'ensemble de jetons associé à cette application logicielle comprend au moins un jeton (E30) :

   une étape de traitement (E50) du paquet de données par ladite application logicielle en utilisant ladite ressource ;

   une étape de décrémentation (E60) de l'ensemble de jetons associé à l'application logicielle d'un nombre de jetons correspondant à une durée d'accès à ladite ressource par l'application logicielle lors de l'étape de traitement dudit paquet ;

   o sinon, une étape de rejet (E40) du paquet de données ; et — sur détection d'au moins un événement de mise à jour relatif à au moins un sous-ensemble d'applications logicielles de la pluralité d'applications logicielles (F10), une étape de mise à jour (PROC2) comprenant :

   o pour chaque application logicielle dudit sous-ensemble :

   une étape de détermination (F20) d'un nombre de jetons destiné à cette application logicielle ; et une étape d'ajout (F40) du nombre de jetons déterminé à l'ensemble de jetons dédié associé à cette application logicielle dans la limite d'un nombre maximum de jetons fixé pour cette application logicielle ; et o si (F50), pour au moins une application logicielle du sous-ensemble, le nombre de jetons déterminé est supérieur au nombre de jetons ajouté, et s'il existe au moins une autre application logicielle de la pluralité d'applications logicielles qui est associée à un ensemble de jetons ayant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette autre application logicielle, une étape de réattribution (F60-F110) du nombre de jetons résiduels à ladite au moins une autre application.
2. 2. Procédé de contrôle selon la revendication 1 dans lequel l'événement de mise à jour détecté (F10) est un instant de mise à jour pour ledit sous-ensemble parmi une pluralité d'instants de mise à jour espacés de façon régulière dans le temps.
3. 3. Procédé de contrôle selon la revendication 1 dans lequel l'événement de mise à jour détecté (F10) est la réception (E10) d'un paquet de données destiné à être traité par une dite application logicielle.
4. 4. Procédé de contrôle selon la revendication 3 dans lequel l'étape de mise à jour (PROC2) est mise en œuvre avant le traitement dudit paquet de données reçu.
5. 5. Procédé de contrôle selon l'une quelconque des revendications 1 à 4 dans lequel deux étapes de mises à jour successives des ensembles de jetons sont espacées d'au moins un intervalle de temps prédéterminé (G10).
6. 6. Procédé de contrôle selon l'une quelconque des revendications 1 à 5 dans lequel lors de l'étape de détermination (F20), le nombre de jetons destiné à l'application logicielle est déterminé à partir d'une vitesse de génération de jetons fixée pour cette application logicielle.
7. 7. Procédé de contrôle selon la revendication 6 dans lequel une même vitesse de génération de jetons est fixée pour chacune des applications logicielles de ladite pluralité d'applications logicielles.
8. 8. Procédé de contrôle selon l'une quelconque des revendications 1 à 7 comprenant, lors de l'étape de mise à jour :

   — une étape d'évaluation (F30) d'un nombre global de jetons résiduels pour le sous-ensemble d'applications logicielles ;

   — une étape d'identification (F60), parmi ladite pluralité d'applications logicielles, des applications logicielles associées à des ensembles dédiés de jetons qui après l'étape d'ajout comprennent des nombres de jetons inférieurs aux nombres maximaux de jetons fixés pour ces applications logicielles ; et — une étape de répartition (F90) entre les applications logicielles identifiées de tout ou partie du nombre global de jetons résiduels dans la limite des nombres maximums de jetons fixés pour les applications logicielles identifiées.
9. 9. Procédé de contrôle selon la revendication 8 dans lequel tant qu'à l'issue de l'étape de répartition, il reste des jetons résiduels et qu'au moins une application logicielle associée à un ensemble de jetons comprenant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette application logicielle peut être identifiée, lesdits jetons résiduels sont répartis entre ladite au moins une application logicielle pouvant être identifiée.
10. 10. Procédé de contrôle selon l'une quelconque des revendications 1 à 9 dans lequel un même nombre maximum de jetons est fixé pour chacune des applications logicielles de ladite pluralité d'applications logicielles.
11. 11. Procédé de contrôle selon l'une quelconque des revendications 1 à 10 dans lequel lors de l'étape de traitement, ladite application logicielle peut accéder à la ressource jusqu'à l'achèvement du traitement sur ledit paquet de données.
12. 12. Procédé de contrôle selon l'une quelconque des revendications 1 à 11 dans lequel ladite ressource est une ressource d'une unité de traitement centrale du système informatique.
13. 13. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté par un ordinateur.
14. 14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de contrôle selon l'une quelconque des revendications 1 à 12.
15. 15. Dispositif de contrôle (3) d'un accès à une ressource d'un système informatique par une pluralité d'applications logicielles destinées à s'exécuter sur le système informatique, ledit dispositif de contrôle comprenant :

    — un module d'association (3A), configuré pour associer à chaque application logicielle un ensemble dédié de jetons, chaque jeton représentant une période de temps prédéterminée d'accès à ladite ressource ;

    — des modules, activés sur réception d'un paquet de données destiné à être traité par une dite application logicielle, et comprenant :

    o un module de traitement (3B) et un module de décrémentation (3C), activés si l'ensemble de jetons associé à ladite application logicielle comprend au moins un jeton, le module de traitement étant configuré pour déclencher le traitement du paquet de données par ladite application logicielle en utilisant ladite ressource, et le module de décrémentation étant configuré pour décrémenter l'ensemble de jetons associé à l'application logicielle d'un nombre de jetons correspondant à une durée d'accès à ladite ressource par l'application logicielle lors du traitement du paquet de données ; o un module de rejet (3D) activé sinon et configuré pour rejeter le paquet de données ; et — un module de mise à jour (3F) activé sur détection d'au moins un événement de mise à jour prédéterminé relatif à au moins un sous-ensemble d'applications logicielles de ladite pluralité d'applications logicielles, ce module de mise à jour comprenant :

    o un module de détermination et un module d'ajout, activés pour chaque application logicielle du sous-ensemble, le module de détermination étant configuré pour déterminer un nombre de jetons destiné à cette application logicielle, et le module d'ajout étant configuré pour ajouter le nombre de jetons déterminé à l'ensemble de jetons associé à l'application logicielle dans la limite d'un nombre maximum de jetons fixé pour cette application logicielle ; et o un module de réattribution, activé si pour au moins une application logicielle du sousensemble d'applications logicielles, le nombre de jetons déterminé est supérieur au nombre de jetons ajouté, et s'il existe au moins une autre application logicielle de la pluralité d'applications logicielles qui est associée à un ensemble de jetons ayant un nombre de jetons inférieur au nombre maximum de jetons fixé pour cette autre application logicielle, ce module de réattribution étant configuré pour réattribuer les jetons résiduels à ladite au moins une autre application.
16. 16. Système informatique (1) comprenant :

    — une pluralité d'applications logicielles (APP1,...,APPN) de traitement de données destinées à s'exécuter sur le système informatique et à accéder à au moins une ressource du système informatique lors de leurs exécutions ; et — un dispositif de contrôle (3) d'un accès à ladite au moins une ressource par la pluralité d'applications logicielles conforme à la revendication 15.