Changes between Version 13 and Version 14 of rpc_implementation

Timestamp:

Jul 16, 2016, 5:45:09 PM (8 years ago)

Author:

alain

Comment:

--

rpc_implementation

@@ -13 +13 @@
 L'architecture cible est généralement clusterisée, ce qui signifie que l'espace d'adressage physique est partagé par tous les CPUs, mais qu'il est partitionné entre les différents clusters. Le nombre de clusters, ainsi que le contenu de chaque cluster sont décrits dans le fichier ''arch-info''. ALMOS-MK supporte les architectures cibles respectant les contraintes suivantes:
  * Les adresses physiques, aussi appelées adresses étendues, sont codées sur 64 bits.
- * La taille maximale de l'espace adressable physique accessible dans un unique cluster est définit par un paramètre global CLUSTER_SIZE_MAX qui est une puissance de 2. Elle vaut 4 Goctets pour TSAR, mais peut posséder une valeur différente (plus grande) pour d'autres architectures. Une adresse physique est donc divisée en deux parties: le champs '''LPA''' est l'adresse locale dans un cluster, et le champs '''CXY''' est le numéro identifiant un cluster particulier.
+ * La taille maximale de l'espace adressable physique accessible dans un unique cluster est définit par le paramètre global CONFIG_CLUSTER_SPAN qui est une puissance de 2. Elle vaut 4 Goctets pour TSAR, mais peut posséder une valeur différente (plus grande) pour d'autres architectures. Une adresse physique est donc divisée en deux parties: le champs '''PTR''' est l'adresse locale dans un cluster, et le champs '''CXY''' est le numéro identifiant un cluster particulier.
  * Chaque cluster peut contenir un nombre quelconque de CPUs (y compris 0), un nombre quelconque de périphériques, et un banc mémoire physique de longueur quelconque (y compris 0). Pour chaque périphérique et pour le banc mémoire, le fichier ''arch_info''  définit l'adresse locale de base, et la longueur du segment associé.
  * Il existe une instance du noyau dans tout cluster contenant au moins un CPU, un contrôleur d'interruptions, et un banc mémoire physique, ce qui n'est pas forcément le cas de tous les clusters. 
@@ -20 +20 @@
 == 2) Point d'accès unique dans chaque cluster ==
 
-Rappelons que toutes les variables globales définies dans le segment KDATA du noyau sont répliquées dans tous les clusters. Deux variables de même nom peuvent avoir des valeurs différentes dans deux clusters différents, mais elles sont rangées à des adresses locales PLA identiques. Cette propriété est fondamentale, puisqu'elle permet à une instance du noyau dans un cluster K d'accéder directement  aux données globales des autres instance du noyau dans un cluster L, en fabricant une adresse physique à partir de l'adresse PLA (commune à tous les clusters) et de l'identifiant du cluster cible CXY.
+Rappelons que toutes les variables globales définies dans le segment KDATA du noyau sont répliquées dans tous les clusters. Deux variables de même nom peuvent avoir des valeurs différentes dans deux clusters différents, mais elles sont rangées à des adresses locales PTR identiques. Cette propriété est fondamentale, puisqu'elle permet à une instance du noyau dans un cluster K d'accéder directement  aux données globales des autres instance du noyau dans un cluster L, en fabricant une adresse physique à partir de l'adresse PTR (commune à tous les clusters) et de l'identifiant CXY du cluster cible.
 
 N'importe quel thread client s'exécutant sur n'importe quel CPU de n'importe quel cluster peut envoyer une RPC vers n'importe quel cluster serveur, identifié par son index CXY. 
@@ -35 +35 @@
 Il existe différents types de RPC : 
  * Une RPC ''simple bloquante'' est envoyée à un seul serveur, et attend une seule réponse.
- * Une RPC ''broadcast bloquante'' est envoyée à N serveurs, et attend N réponses.
+ * Une RPC ''multicast bloquante'' est envoyée à N serveurs, et attend N réponses.
  * Une RPC ''simple non bloquante'' est envoyée à un seul serveur et n'attend pas de réponse.
- * Une RPC ''broadcast non bloquante'' est envoyée à N serveurs et n'attend pas de réponse.
+ * Une RPC ''multicast non bloquante'' est envoyée à N serveurs et n'attend pas de réponse.
 
 Chaque case d'une RPC_FIFO contient un pointeur étendu (xptr_t) sur un descripteur de RPC (rpc_desc_t), qui est toujours stocké dans la mémoire du cluster client.  
@@ -43 +43 @@
  * Le champs '''index''' définit le type de service demandé (de façon similaire à un index d'appel système).
  * Le champs '''response''' est un entier qui défini le nombre de réponses attendues.
- * Le champs '''args''' est un tableau de 32 uint32_t contenant les arguments d'entrée et de sortie.
+ * Le champs '''args''' est un tableau de 8 uint64_t contenant les arguments d'entrée et de sortie.
 Pour une RPC bloquante, le client initialise le champs '''response''' avec le nombre de réponses attendus, et chaque serveur concerné le décrémente au moyen d'un accès ''remote_atomique_add()''.
 L'utilisation et l'interprétation du tableau '''args''' dépend de chaque type de RPC.
@@ -52 +52 @@
 
 L'introduction d'une nouvelle RPC nécessite de modifier le code de ALMOS-MK de la façon suivante:
- * Il faut définir ou identifier la fonction système ''my_kernel_service()'' qu'on souhaite exécuter à distance. Le nombre de paramètres d'entrée ou de sortie ne doit pas être supérieur à 32.
+ * Il faut définir ou identifier la fonction système ''my_kernel_service()'' qu'on souhaite exécuter à distance. Le nombre de paramètres d'entrée ou de sortie ne doit pas être supérieur à 8.
  * La nouvelle RPC doit être enregistrée dans l'enum ''rpc_index_t'' (fichier rpc.h) et dans le tableau ''rpc_exec[]'' (fichier rpc.c).
  * Il faut écrire explicitement la fonction de marshaling ''rpc_my_kernel_service_client()'' qui est exécutée du côté client pour (1) enregistrer les arguments d'entrée dans le descripteur de RPC, (2) poster la RPC dans la RPC_FIFO, (3) récupérer les arguments de sortie dans le descripteur de RPC.