Surveillance des performances iftask et NPU sur QvPC-DI
Introduction
Ce document décrit comment surveiller les performances de iftask / NPU sur QvPC-DI.
Il fournit également plus d'informations sur certains concepts clés d'iftask.
Composants utilisés
Les informations de ce document sont basées sur QvPC-DI.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Architecture Iftask
iftask est un processus dans QvPC-DI. Elle active la fonctionnalité DPDK (Data Plane Development Kit) sur la carte virtuelle de fonction de service (SF) et la carte virtuelle de fonction de contrôle (CF) pour les ports réseau DI et les ports de service. DPDK est un moyen plus efficace de gérer les entrées/sorties dans les environnements virtualisés.
Les pilotes de périphériques des contrôleurs d'interface réseau (NIC) hautes performances sont maintenant déplacés vers l'espace utilisateur, ce qui évite les commutateurs de contexte coûteux (espace utilisateur/espace noyau).
Les pilotes s'exécutent en mode non interruptible dans l'espace utilisateur, et les threads ont un accès direct aux files d'attente matérielles/tampons d'anneau dans ces pilotes de carte réseau.
La documentation relative à l'architecture est disponible à :
Guide d'administration de la plate-forme Ultra Services Platform (USP) à partir de la plate-forme Ultra Gateway.
Disponibilité pour différentes versions.
En détail si l'architecture des tâches (pour SF) est vue dans ce schéma :
Différents composants sont présents :
Pilote de mode de sondage (PMD) : Il s'agit de la fonction qui interroge en permanence les files d'attente matérielles à partir des cartes réseau (dans le cas de SR-IOV) ou des tampons d'anneau logiciels (dans le cas d'interfaces de type virtio/vmxnet). C'est pourquoi le CPU associé à ces PMD est en permanence ancré à 100%.
Pendant le déploiement, les nr des CPU alloués à iftask et à diverses fonctions au sein d'iftask peuvent être alloués statiquement via le fichier param.cfg.
Boxertap : ajout/suppression de métadonnées staros (en-tête MEH) aux paquets en fonction de leur provenance (par exemple : Di port/service port), et où il doit être envoyé (ex : vNPU local)
IOMUX : Possède une bibliothèque BIA avec toutes les destinations (sessmgr's/ports/vNPU's/..). Cette fonction consiste essentiellement à acheminer les paquets en fonction de leur BIA
vNPU : Classification/recherche de flux. Cette configuration est comparable à celle du processeur réseau des systèmes matériels (ASR5000/ASR5500).
Les flux dans vNPU sont toujours programmés par NPUmgr (qui obtient ses informations de demuxmgr/sessmgr etc) dans la mémoire partagée qui est accessible par vNPU.
-En outre, une API est créée de sorte que npumgr/sessmgr puisse interroger le vNPU pour les statistiques/la configuration
MCDMA : les paquets destinés à sessmgr sont écrits sur l'interface MCDMA (via les différents coeurs/threads MCDMA disponibles). Ces paquets sont ensuite mis à la disposition de sessmgr via DMA. Cela permet d'améliorer les performances car le noyau n'est impliqué que de façon limitée. Ceci est expliqué plus en détail dans cet article.
MCDMA offre également des fonctionnalités de traitement par lots (pour gérer plusieurs paquets dans un appel système).
KNI : pour les paquets qui doivent aller vers le noyau Linux (DI control/ARP/icmp/routing/...)
Flux De Paquets Iftask
Le schéma ci-dessous explique le flux de paquets d’un paquet du plan de contrôle. Exemple : Demande de création de session GTPv2
Étape 1 : Le paquet CSR GTPv2 arrive par le port de service sur l'un des SF disponibles. Il sera placé dans les files d'attente Rx de la carte réseau de l'interface de service, et récupéré par l'un des coeurs PMD du processus iftask. Boxertap placera l'en-tête MEH et le paquet sera transféré via IOMux vers le vNPU local pour la recherche de flux.
Puisqu'il s'agit d'une nouvelle session, le vNPU n'a aucun flux spécifique programmé pour cela, et il devra acheminer le paquet vers le demuxmgr sur la carte demux.
Étape 2 : vNPU modifie l'en-tête MEH (avec un nouveau BIA pour le processus de démultiplexage approprié). IOMUX sait qu'il doit l'envoyer sur le réseau DI vers la carte demux. Si le processus task sur la carte Demux gère le paquet entrant, et IOMux le route vers le module KNI (qui est l'interface vers le noyau). Par le noyau, il finira par se retrouver dans le processus demuxmgr (egtpinmgr dans ce cas).
Étape 3 : Le Demuxmgr effectuera ses tâches. Sélectionnez un sessmgr et programmez npumgr avec les flux pour les paquets GTPv2 suivants
Les vNPU de toutes les cartes pourront accéder à la mémoire partagée que npumgr utilise pour programmer ces flux.
Étape 4 : Le CSR GTPv2 est maintenant transféré au sessmgr sélectionné. Son MEH est changé à nouveau, et transféré de la carte Demux, sur le réseau DI vers la carte Sessmgr SF. Le processus IOMUX sur cette carte transfère le paquet via l'interface MCDMA vers le sessmgr sélectionné. À partir de là, sessmgr gérera tout le trafic GTPv2 pour cette session. Une fois les TEID GTPU négociés, il programmera les flux via NPUmgr de sorte que les paquets GTPU suivants puissent également aller directement de la carte SF entrante à la carte SF sessmgr.
vCPU dans iftask
Pendant le déploiement, une certaine quantité d'unités centrales virtuelles (vCPU) est allouée de manière statique au processus iftask. Cela réduit la quantité de coeurs pour les applications d'espace utilisateur (sessmgr, etc.), mais améliore considérablement les performances d'E/S.
Cette allocation est effectuée via le paramètre ci-dessous dans ce modèle param.cfg qui est associé à chaque SF/CF pendant le déploiement :
- IFTASK_CORES (% des coeurs disponibles à affecter avec iftask)
- (IFTASK_CRYPTO_CORES - (% des coeurs disponibles à attribuer pour le traitement cryptographique (dans le cas d'EPDG))
- (IFTASK_MCDMA_CORES - (pour affiner le nombre de coeurs alloués à la fonctionnalité MCDMA)
- Sur un SF, le processus iftask répartit en interne les coeurs qui lui sont affectés dans :
- Pilotes PMD (Poll Mode Drivers) vCPU (exercice tx/rx/vnpu)
- vCPU MCDMA, transfert de paquets d'iftask à sessmgr et inversement
- Sur un CF, aucun vCPU MCDMA n'est requis, car les SF n'hébergent pas de processus sessmgr.
La commande « show cloud hardware iftask » donne plus de détails sur ce point sur votre déploiement QVPC-DI :
[local]UGP# show cloud hardware iftask Card 1: Total number of cores on VM: 8 Number of cores for PMD only: 0 Number of cores for VNPU only: 0 Number of cores for PMD and VNPU: 2 <-- CF: 2 out of 8 cores are assigned to iftask PMD/VNPU Number of cores for MCDMA: 0 <-- CF: no cores allocated to MCDMA as there is no sessmgr process on CF Number of cores for Crypto: 0 Hugepage size: 2048 kB Total hugepages: 3670016 kB NPUSHM hugepages: 0 kB CPU flags: avx sse sse2 ssse3 sse4_1 sse4_2 Poll CPU's: 1 2 KNI reschedule interval: 5 us ... Card 3: Total number of cores on VM: 8 Number of cores for PMD only: 0 Number of cores for VNPU only: 0 Number of cores for PMD and VNPU: 2 <-- SF: 2 out of 8 core are assigned to iftask PMD/VNPU
Number of cores for MCDMA: 1 <-- SF: 1 out of 8 cores is assigned to iftak MCDMA
Number of cores for Crypto: 0
Hugepage size: 2048 kB
Total hugepages: 4718592 kB
NPUSHM hugepages: 0 kB
CPU flags: avx sse sse2 ssse3 sse4_1 sse4_2
Poll CPU's: 1 2 3
KNI reschedule interval: 5 us
La commande 'show cloud configuration' donnera plus de détails sur les paramètres utilisés :
[local]UGP# show cloud configuration Card 1: Config Disk Params: ------------------------- CARDSLOT=1 CPUID=0 CARDTYPE=0x40010100 DI_INTERFACE=BOND:TYPE:ixgbevf-1,TYPE:ixgbevf-2 DI_INTERFACE_VLANID=2111 VNFM_INTERFACE=MAC:fa:16:3e:23:aa:e9 VNFM_PROXY_ADDRS=172.16.180.3,172.16.180.5,172.16.180.6 MGMT_INTERFACE=MAC:fa:16:3e:87:23:9b VNFM_IPV4_ENABLE=true VNFM_IPV4_DHCP_ENABLE=true Local Params: ------------------------- CARDSLOT=1 CARDTYPE=0x40010100 CPUID=0 ... Card 3: Config Disk Params: ------------------------- CARDSLOT=3 CPUID=0 CARDTYPE=0x42030100 DI_INTERFACE=BOND:TYPE:ixgbevf-1,TYPE:ixgbevf-2 SERVICE1_INTERFACE=BOND:TYPE:ixgbevf-3,TYPE:ixgbevf-4 SERVICE2_INTERFACE=BOND:TYPE:ixgbevf-5,TYPE:ixgbevf-6 DI_INTERFACE_VLANID=2111 VNFM_INTERFACE=MAC:fa:16:3e:29:c6:b7 IFTASK_CORES=30 VNFM_IPV4_ENABLE=true VNFM_IPV4_DHCP_ENABLE=true Local Params: ------------------------- CARDSLOT=3 CARDTYPE=0x42010100 CPUID=0
Considérations conceptuelles:
Il y a un certain nombre de facteurs qui doivent être pris en compte lors de l'allocation de vCPU à iftask.
-nombre total de vCPU disponibles pour le SF par rapport aux vCPU iftask : La configuration par défaut spécifie 30 % des vCPU associés à iftask via le paramètre IFTASK_CORES dans le fichier param.cfg. Mais cela peut varier selon l'application (MME vs SPGW vs ePDG) —> À consulter avec l'ingénierie.
-iftask vCPU alloués à PMD vs iftask vCPU alloués à MCDMA. Pour vérifier si cette opération est équilibrée, reportez-vous à la section relative aux performances iftask ci-dessous.
-iftask vCPU MCDMA par rapport aux vCPU restants pour toutes les applications. Généralement, il est bon d'avoir une distribution 1/x des vCPU iftask MCDMA par rapport aux vCPU restants pour les applications (sessmgr/aamgr/...).
Exemple :
Total des coeurs 38 disponibles pour SF :
-14 affectés à iftask (6 PMD, 8 MCDMA)
- 24 sont affectés à d'autres processus
Ce qui signifie qu'il y a 1 vCPU MCDMA pour chaque 3 vCPU d'application.
cela permet d'assurer une charge égale pour chaque vCPU MCDMA.
Surveillance des performances iftask
Le processus iftask peut être surveillé de plusieurs manières.
Consolidez la liste des commandes show :
show subscribers data-rate show npumgr dinet utilization pps show npumgr dinet utilization pps show cloud monitor di-network summary show cloud hardware iftask show cloud configuration show iftask stats summary show port utilization table show npu utilization table show npumgr utilization information show processes cpu
La commande #show cpu info verbose ne donnera pas d'informations sur les coeurs iftask. Ils seront toujours répertoriés à 100 % d'utilisation.
Dans l'exemple ci-dessous, les ressources de base 1,2,3 sont associées à iftask et sont répertoriées à 100 % d'utilisation, ce qui est attendu.
Card 3, CPU 0:
Status : Standby, Kernel Running, Tasks Running
Load Average : 3.12, 3.12, 3.13 (3.95 max)
Total Memory : 16384M
Kernel Uptime : 4D 21H 56M
Last Reading:
CPU Usage All : 1.9% user, 0.3% sys, 0.0% io, 0.0% irq, 97.8% idle
Core 0 : 5.8% user, 0.2% sys, 0.0% io, 0.0% irq, 94.0% idle
Core 1 : Not Averaged (Poll CPU)
Core 2 : Not Averaged (Poll CPU)
Core 3 : Not Averaged (Poll CPU)
Core 4 : 2.2% user, 0.2% sys, 0.0% io, 0.0% irq, 97.6% idle
Core 5 : 0.8% user, 0.5% sys, 0.0% io, 0.0% irq, 98.7% idle
Core 6 : 0.4% user, 0.5% sys, 0.0% io, 0.0% irq, 99.1% idle
Core 7 : 0.1% user, 0.3% sys, 0.0% io, 0.0% irq, 99.6% idle
Poll CPUs : 3 (1, 2, 3)
Core 1 : 100.0% user, 0.0% sys, 0.0% io, 0.0% irq, 0.0% idle
Core 2 : 100.0% user, 0.0% sys, 0.0% io, 0.0% irq, 0.0% idle
Core 3 : 100.0% user, 0.0% sys, 0.0% io, 0.0% irq, 0.0% idle
Processes / Tasks : 143 processes / 16 tasks
Network mcdmaN : 0.002 kpps rx, 0.001 mbps rx, 0.002 kpps tx, 0.001 mbps tx
File Usage : 1504 open files, 1627405 available
Memory Usage : 7687M 46.9% used
Memory Details:
Static : 330M kernel, 144M image
System : 10M tmp, 0M buffers, 54M kcache, 79M cache
Process/Task : 6963M (120M small, 684M huge, 6158M other)
Other : 104M shared data
Free : 8696M free
Usable : 5810M usable (8696M free, 0M reclaimable, 2885M reserved by tasks)La commande #show npu used table donnera un bon résumé sur l'utilisation de chaque coeur associé au processus iftask (sur chaque carte).
[local]UGP# show npu utilization table
-------iftask-------
lcore now 5min 15min
-------- ------ ------ ------
01/0/1 0% 0% 0%
01/0/2 0% 0% 0%
02/0/1 0% 0% 0%
02/0/2 2% 1% 0%
03/0/1 0% 0% 0%
03/0/2 0% 0% 0%
03/0/3 0% 0% 0%
04/0/1 0% 0% 0%
04/0/2 0% 0% 0%
04/0/3 0% 0% 0%
05/0/1 0% 0% 0%
05/0/2 0% 0% 0%
05/0/3 0% 0% 0%Commande #show npumgr utilisation information (commande masquée)
Cette commande donne plus d'informations sur chaque coeur iftask, et sur ce qui consomme le CPU sur ces coeurs.
Les coeurs PMD et MCDMA doivent avoir une charge relativement uniforme.
Si ce n'est pas le cas, un certain réglage peut être nécessaire (allocation de plus/moins de coeurs MDMA par exemple).
******** show npumgr utilization information 3/0/0 *******
5-Sec Avg: lcore01| lcore02| lcore03| lcore04| lcore05| lcore06| lcore07| lcore08| lcore09| lcore10| lcore11| lcore12| lcore13| lcore14| lcore15| lcore16|
Idle: 31%| 37%| 32%| 35%| 41%| 48%| 47%| 38%| 57%| 56%| 55%| 56%| 46%| 56%| 54%| 52%|
PortRX: 28%| 26%| 27%| 26%| 0%| 0%| 0%| 0%| 12%| 14%| 11%| 11%| 0%| 0%| 0%| 0%|
PortTX: 5%| 5%| 6%| 5%| 8%| 8%| 8%| 14%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%|
KniRX: 6%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%|
Kni: 1%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%| 0%|
McdmaRX: 0%| 0%| 0%| 0%| 34%| 29%| 29%| 32%| 0%| 0%| 0%| 0%| 35%| 28%| 28%| 28%|
Mcdma: 0%| 0%| 0%| 0%| 11%| 7%| 4%| 6%| 0%| 0%| 0%| 0%| 14%| 7%| 7%| 7%|
Vnpu: 28%| 29%| 28%| 32%| 0%| 0%| 0%| 0%| 30%| 28%| 33%| 28%| 0%| 0%| 0%| 0%|
McdmaFlush: 0%| 0%| 0%| 0%| 6%| 8%| 12%| 10%| 0%| 0%| 0%| 0%| 6%| 10%| 11%| 14%|
Cipher: 1%| 2%| 6%| 2%| 0%| 0%| 0%| 0%| 1%| 2%| 1%| 5%| 0%| 0%| 0%| 0%|
rx kbits/sec: 728563| 736103| 647535| 626595| 811362| 698724| 717147| 799281| 617199| 595268| 623670| 633132| 819270| 672732| 790849| 719498|
rx frames/sec: 94409| 95586| 91107| 84997| 109526| 97466| 98557| 107690| 81122| 82076| 86959| 87960| 114114| 96198| 108108| 100259|
tx kbits/sec: 715038| 722181| 634227| 614221| 827124| 712740| 731329| 814782| 605373| 583318| 611001| 620328| 835692| 686575| 806395| 733924|
tx frames/sec: 94310| 95491| 90969| 84896| 109526| 97466| 98557| 107690| 81002| 81986| 86858| 87859| 114114| 96198| 108108| 100259|
5-Min Avg: ...
15-Min Avg: ...plus d'explications :
Le CPU est comptabilisé comme suit pour un paquet entrant dans un processus iftask via le port de service ou le port DI.
La recherche Vnpu est la partie la plus intensive du processeur.
Si après la recherche Vnpu :
-Si le paquet est envoyé au coeur MCDMA, le temps CPU sera pris en compte sur le McdmaRx du coeur MCDMA concerné.
-Si le paquet est envoyé à un autre coeur iftask, le temps CPU sera pris en compte sous Vnpu
- Si le paquet est envoyé sur le même coeur iftask, le temps CPU sera pris en compte sous PortRx
-Si le paquet est envoyé sur le même coeur iftask, le temps CPU sera pris en compte sous KniRx
PortRx inclut également une surcharge générale importante pour extraire les paquets des files d'attente de réception et les envoyer/mettre en file d'attente vers l'endroit où ils doivent se rendre
Commandes #show npumgr dinet use pps, #show npumgr dinet use bbps et #show port use table
Ils fournissent des informations sur la charge des ports DI et des ports de services.
Les performances réelles dépendent de l'allocation de la carte réseau/du processeur et du processeur pour iftask.
[local]UGP# show npumgr dinet utilization pps
------ Average DINet Port Utilization (in kpps) ------
Port Type Current 5min 15min
Rx Tx Rx Tx Rx Tx
----- ------------------------ ------- ------- ------- ------- ------- -------
1/0 Virtual Ethernet 0 0 0 0 0 0
2/0 Virtual Ethernet 0 0 0 0 0 0
3/0 Virtual Ethernet 0 0 0 0 0 0
4/0 Virtual Ethernet 0 0 0 0 0 0
5/0 Virtual Ethernet 0 0 0 0 0 0
[local]UGP# show npumgr dinet utilization bps
------ Average DINet Port Utilization (in mbps) ------
Port Type Current 5min 15min
Rx Tx Rx Tx Rx Tx
----- ------------------------ ------- ------- ------- ------- ------- -------
1/0 Virtual Ethernet 1 1 1 1 1 1
2/0 Virtual Ethernet 1 0 1 0 1 0
3/0 Virtual Ethernet 0 0 0 0 0 0
4/0 Virtual Ethernet 0 0 0 0 0 0
5/0 Virtual Ethernet 0 0 0 0 0 0
[local]UGP# show port utilization table
------ Average Port Utilization (in mbps) ------
Port Type Current 5min 15min
Rx Tx Rx Tx Rx Tx
----- ------------------------ ------- ------- ------- ------- ------- -------
1/1 Virtual Ethernet 0 0 0 0 0 0
2/1 Virtual Ethernet 0 0 0 0 0 0
3/10 Virtual Ethernet 0 0 0 0 0 0
3/11 Virtual Ethernet 0 0 0 0 0 0
4/10 Virtual Ethernet 0 0 0 0 0 0
4/11 Virtual Ethernet 0 0 0 0 0 0
5/10 Virtual Ethernet 0 0 0 0 0 0
5/11 Virtual Ethernet 0 0 0 0 0 0Commande #show cloud monitor di-network summary
Cette commande surveille l'intégrité du réseau DI. Les cartes s'envoient des pulsations et la perte est surveillée. Dans un système sain, aucune perte n'est signalée.
[local]UGP# show cloud monitor di-network summary Card 3 Heartbeat Results: ToCard Health 5MinLoss 60MinLoss 1 Good 0.00% 0.00% 2 Good 0.00% 0.00% 4 Good 0.00% 0.00% 5 Good 0.00% 0.00% Card 4 Heartbeat Results: ToCard Health 5MinLoss 60MinLoss 1 Good 0.00% 0.00% 2 Good 0.00% 0.00% 3 Good 0.00% 0.00% 5 Good 0.00% 0.00% Card 5 Heartbeat Results: ToCard Health 5MinLoss 60MinLoss 1 Good 0.00% 0.00% 2 Good 0.00% 0.00% 3 Good 0.00% 0.00% 4 Good 0.00% 0.00%
Commande #show iftask stats summary
Avec des charges NPU plus élevées, il est possible que le trafic soit abandonné.
Pour évaluer cela, la commande #show iftask stats summary peut être utilisée.
[local]VPC# show iftask stats summary Thursday January 18 16:01:29 IST 2018 ----------------------------------------------------------------------------------------------- Counter SF3 SF4 SF5 SF6 SF7 SF8 SF9 SF10 SF11 SF12 ___TOTAL___ ------------------------------------------------------------------------------------------------ svc_rx 32491861127 16545600654 37041906441 37466889835 32762859630 34931554543 38861410897 16025531220 33566817747 32823851780 312518283874 svc_tx 46024774071 14811663244 40316226774 39926898585 40803541378 48718868048 35252698559 1738016438 4249156512 40356388348 312198231957 di_rx 42307187425 14637310721 40072487209 39584697117 41150445596 44534022642 31867253533 1731310419 4401095653 40711142205 300996952520 di_tx 28420090751 16267050562 36423298668 36758561246 32731606974 30366650898 35201117980 16009902791 33536789041 32815316570 298530385481 __ALL_DROPS__ 1932492 252 17742 790473 11228 627018 844812 60402 0 460830 4745249 svc_tx_drops 0 0 0 0 0 0 0 0 0 0 0 di_rx_drops 0 1 0 0 49 113 579 30200 0 4888 35830 di_tx_drops 0 0 0 0 0 0 0 0 0 0 0 sw_rss_enq_drops 0 0 0 0 0 0 0 0 0 0 0 kni_thread_drops 0 0 0 0 0 0 0 0 0 0 0 kni_drops 0 1 0 0 0 0 124 30200 0 0 30325 mcdma_drops 0 0 0 168 80 194535 758500 0 0 11628 964911 mux_deliver_hop_drops 0 0 0 0 0 0 0 0 0 1019 1019 mux_deliver_drops 0 0 0 0 0 0 0 0 0 0 0 mux_xmit_failure_drops 0 3 0 0 0 0 7 2 0 0 12 mc_dma_thread_enq_drops 0 0 0 0 49 113 580 0 0 3457 4199 sw_tx_egress_enq_drops 1904329 0 0 787971 9004 429214 85022 0 0 429810 3645350 cpeth0_drops 0 0 0 0 0 0 0 0 0 0 0 mcdma_summary_drops 28163 247 17742 2334 2046 3043 0 0 0 10028 63603 fragmentation_err 0 0 0 0 0 0 0 0 0 0 0 reassembly_err 0 0 0 0 0 0 0 0 0 0 0 reassembly_ring_enq_err 0 0 0 0 0 0 0 0 0 0 0 __DISCARDS__ 20331090 9051092 23736055 23882896 23807520 24231716 24116576 8944291 22309474 20135799 20135799
SW-RSS et HW-RSS
RSS est une fonctionnalité capable de distribuer le trafic entrant provenant d'une carte réseau sur plusieurs processeurs DPDK. En général, la carte réseau prend en charge RSS dans le matériel, ce qui lui permet de distribuer le trafic sur plusieurs coeurs iftask.
Le processus iftask de Staros a mis en oeuvre une version logicielle de rss qui peut être activée si :
-nic ne prend pas en charge HW rss (et donc tout le trafic tx/rx atterrira sur un seul CPU iftask).
-nic n'a pas assez de files d'attente tx/rx (moins de files d'attente que les CPU tx/rx disponibles assignés à iftask). Dans ce cas, le SW-RSS (complet) permet une distribution correcte sur tous les coeurs iftask disponibles attribués pour rx/tx.
Cette fonctionnalité ne fonctionne que pour le trafic entrant par les ports de service. Le trafic DI n'est pas pris en compte.
Il existe trois modes de configuration :
-no iftask sw-rss - sw-rss désactivé. Le système repose sur le RSS matériel.
-iftask sw-rss complet - utilisation de sw rss pour tout le trafic. RSS de logiciel peut fonctionner avec RSS de matériel. Il n'est pas nécessaire de désactiver HW RSS. Mais le RSS logiciel sera responsable de l'équilibrage de charge réel du trafic SERVICE vers les coeurs iftask.
-iftask sw-rss supplemental - utilisation de sw rss uniquement pour le trafic non pris en charge par hw-rss (exemple : trafic MPLS)
Avec RSS matériel et logiciel, il est important de comprendre comment le trafic est haché dans les différents processeurs iftask/dpdk.
RSS MATÉRIEL : le hachage dépend du matériel. En voici un exemple :
[root@host]# ethtool -n enp10s0f1
4 RX rings available
Total 0 rules
[root@host] # ethtool -n enp10s0f0 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
SW RSS : À partir de Staros 21.6, le hachage de la version RSS du logiciel se comporte comme suit :
1. In case of IPV6
we only support L3( IP src/dst ) based hashing (same as the old behaviour).
2. In case of IPV4
a. For TCP we support IP src/dst + tcp ports src/dst
b. For UDP fragmented - only IP src/dst
c. For UDP non-fragmented not gtpu ( I.e. Port !=2152) ? IP src/dst + udp port src/dst
d. For UDP non-fragmented and gtpu ( I.e. Port ==2152) - IP src/dst + udp port src/dst + gtp tunnel id
e. Any other protocol ? we default back to IP src/dst
Important : RSS pour le trafic DI chiffré :
En l'absence de SW-RSS (supplémentaire/complet), il est possible que tout le trafic DI chiffré soit haché dans un seul coeur sur iftask.
Ce coeur sera donc systématiquement plus utilisé que les autres.
Depuis CSCvi06080 
, ceci peut maintenant être atténué par cette commande de configuration :
iftask di-net-encrypt-rss
Après intégration de CSCvm41257 , cette option sera définie par défaut.
Plus d'informations détaillées sur RSS logiciel :
L'objectif de sw-rss est d'équilibrer la charge des coeurs PMD et d'éviter les scénarios de limitation de débit où un coeur PMD atteint son maximum lorsque les autres ont une capacité disponible importante.
Tous les paquets d'entrée du port de service sont retirés de la carte réseau et reçoivent l'encapsulation MEH par le coeur PMD desservant la file d'attente Rx sur laquelle ils arrivent.
À ce stade, iftask ne sait pas où envoyer le paquet. Les paquets doivent être traités par le VNPU pour déterminer la destination interne. Pratiquement tous ces paquets passent par la recherche de flux/IOC lorsqu’ils sont transférés au VNPU. Les exceptions concernent les abandons pour des raisons telles que VLAN non configuré/désactivé ou MAC de destination non valide (il y a aussi le scénario de transfert L3, mais c'est rare).
Si sw-rss n'est pas configuré, le traitement de la recherche de flux/IOC VNPU se produit sur le même coeur immédiatement après l'encapsulation MEH. Si sw-rss est configuré, les paquets sont mis en file d'attente vers un coeur pour un traitement VNPU basé sur un hachage. L'opération de recherche de flux/IOC VNPU est la fonction iftask la plus coûteuse ; sw-rss nous permet d'équilibrer cette charge de travail sur tous les coeurs PMD.
À la suite de la recherche de flux/IOC VNPU, le paquet est soit transmis à un autre SF via la transmission DINet, soit mis en file d'attente vers l'application locale via le transfert MCDMA (encore une fois, il y a des exceptions, mais je ne pense pas qu'elles soient pertinentes pour cette discussion).
Les paquets envoyés à un autre SF sont directement mis en file d'attente vers le canal MCDMA approprié sur la carte de destination suivant DINet Rx. Ils ne nécessitent pas de (seconde) passe VNPU.
Files d'attente TX/RX
Dans les journaux iftask, nous pouvons voir des journaux comme :
Tue May 7 15:26:48 2019 PID:8188 APP: max rx queues supported 16 ...
Tue May 7 15:26:48 2019 PID:8188 APP: max tx queues supported 8 ...
Tue May 7 15:26:48 2019 PID:8188 APP: hw rx requested 2 ...
Tue May 7 15:26:48 2019 PID:8188 APP: hw tx requested tx 5
Cela est lié au nombre de files d'attente RX et TX prises en charge par le matériel réel par rapport au nombre de files d'attente TX/RX qui traitent les demandes de tâches.
Ce que demande iftask est étroitement lié au nombre de processeurs alloués à iftask.
Remarque : Chaque pilote est différent. Certains hôtes de requête, d'autres sont codés en dur.
Le nombre de hw tx demandé est le nombre de coeurs que dpdk utilise. Il s'agit généralement d'un de plus que le nombre total de coeurs alloués à iftask car dpdk inclut le coeur sur lequel le thread de contrôle/ipc s'exécute. Ce coeur est partagé avec boxer et planifié comme un processeur à usage général (le thread dpdk control/ipc n'utilise pas beaucoup de processeur).
Le nombre de rx demandés correspond généralement au nombre de coeurs PMD.
Si task alloue la valeur min (demandée, max) pour chaque port et les distribue sur les coeurs. L'algorithme de distribution est un peu compliqué. L'objectif est de répartir la charge de travail aussi uniformément que possible sur tous les coeurs.
Iftask txbatch
Depuis la version 21.9, staros dispose des options de configuration iftask par défaut suivantes, qui sont importantes pour le traitement par lots (agrégation du trafic). Cela a un impact négatif sur les performances lorsque le noeud est testé avec un seul (ou quelques) abonnés.
# iftask mcdmatxbatch burst size 32 # iftask mcdmatxbatch latency 200 # iftask txbatch burst size 32 # iftask txbatch latency 200
Plus d'explications sur ce sujet sont dans un autre :
Bulkstats
Le schéma Bulkstat est développé pour les performances QPVC-DI liées à iftask/dinet. Ceci est utile pour surveiller le dinet, les ports de service et l'utilisation de l'unité centrale du point de vue des performances/de la charge :
card schema iftask-dinet format EMS,IFTASKDINET,%date%,%time%,%dinet-rxpkts-curr%,%dinet-txpkts-curr%,%dinet-rxpkts-5minave%,%dinet-txpkts-5minave%,%dinet-rxpkts-15minave%,%dinet-txpkts-15minave%,%dinet-txdrops-curr%,%dinet-txdrops-5minave%,%dinet-txdrops-15minave%,%npuutil-now% file 2 port schema iftask-port format EMS,IFTASKPORT,%date%,%time%,%util-rxpkts-curr%,%util-txpkts-curr%,%util-rxpkts-5min%,%util-txpkts-5min%,%util-rxpkts-15min%,%util-txpkts-15min%,%util-txdrops-curr%,%util-txdrops-5min%,%util-txdrops-15min% file 3 card schema npu-util format EMS,NPUUTIL,%date%,%time%,%npuutil-now%,%npuutil-5minave%,%npuutil-15minave%,%npuutil-rxbytes-5secave%,%npuutil-txbytes-5secave%,%npuutil-rxbytes-5minave%,%npuutil-txbytes-5minave%,%npuutil-rxbytes-15minave%,%npuutil-txbytes-15minave%,%npuutil-rxpkts-5secave%,%npuutil-txpkts-5secave%,%npuutil-rxpkts-5minave%,%npuutil-txpkts-5minave%,%npuutil-rxpkts-15minave%,%npuutil-txpkts-15minave%
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
09-Jun-2018
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)