Bewaken van iftask- en NPU-prestaties op QvPC-DI
Inleiding
In dit document wordt beschreven hoe de prestaties van iftask/NPU op QvPC-DI kunnen worden gecontroleerd.
Het biedt ook meer informatie over enkele belangrijke concepten van iftask.
Gebruikte componenten
De informatie in dit document is gebaseerd op QvPC-DI.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
IFTASK-architectuur
iftask is een proces in QvPC-DI. Het maakt Data Plane Development Kit (DPDK) functionaliteit op de Service Function Virtual Card (SF) en Control Function Virtual Card (CF) voor de DI-netwerkpoorten en de service poorten. DPDK is een efficiëntere manier om invoer/uitvoer in gevirtualiseerde omgevingen te verwerken.
De apparaatstuurprogramma's van de krachtige netwerkinterfacecontrollers (NIC's) worden nu verplaatst naar de gebruikersruimte, waardoor kostbare contextuele switches (userspace/kernelspace) worden vermeden.
De stuurprogramma's worden in de ononderbroken modus uitgevoerd in de gebruikersruimte en threads hebben directe toegang tot de HW-wachtrijen/ringbuffers in deze NIC-stuurprogramma's.
Documentatie over architectuur is beschikbaar op:
Ultra Services Platform (USP) Introductie van de systeembeheergids van het Ultra Gateway-platform.
Beschikbaarheid voor verschillende versies.
Diepgaand als taakarchitectuur (voor SF) wordt gezien in dit diagram:
Er zijn verschillende componenten aanwezig:
Stuurprogramma poll-modus (PMD): Dit is de functie die continu de HW-wachtrijen polst van de NIC's (in het geval van SR-IOV) of de SW-ringbuffers (in het geval van virtio/vmxnet-type interfaces). Dit is de reden waarom de CPU's die aan deze PMD's zijn gekoppeld, continu op 100% zijn gekoppeld.
Tijdens de implementatie kunnen de nr's van CPU's die zijn toegewezen aan iftask en aan verschillende functies binnen iftask statisch worden toegewezen via het bestand param.cfg.
Boxertap: toevoegen/verwijderen van steros-metagegevens (MEH-header) aan pakketten op basis van waar het pakket vandaan komt (bijv. Di-poort/servicepoort) en waar het moet worden verzonden (bijv. lokale vNPU)
IOMUX: Heeft een BIA-bibliotheek met alle bestemmingen (sessmgr's/ports/vNPU's/..). Deze functie routeert de pakketten op basis van hun BIA
vNPU: -stroomclassificatie/opzoeken. Dit is vergelijkbaar met de NPU in de HW-gebaseerde systemen (ASR5000/ASR5500).
De stromen in vNPU worden nog steeds geprogrammeerd door NPUmgr (die zijn informatie krijgt van demuxmgr's / sessmgr etc) in gedeeld geheugen dat toegankelijk is via vNPU.
-Daarnaast is er een API gemaakt zodat npumgr/sessmgr de vNPU kan pollen voor statistieken/configuratie
MCDMA: pakketten die bestemd zijn voor sessimgr worden geschreven naar de MCDMA-interface (via de verschillende MCDMA-cores/threads die beschikbaar zijn). Deze pakketten worden vervolgens via DMA beschikbaar gesteld aan sessmgr. Dit zorgt voor een echte prestatieboost omdat de kernel slechts in beperkte mate betrokken is. Dit wordt verder uitgelegd in dit artikel.
MCDMA biedt ook batchmogelijkheden (om veel pakketten in één systeemaanroep te verwerken).
KNI: interface voor pakketten die naar linux kernel moeten gaan (DI control/ARP/icmp/routing/...)
IFTASK-pakketstroom
In het onderstaande diagram wordt de pakketstroom van een controlevliegtuigpakket uitgelegd. Voorbeeld: GTPv2 Sessieverzoek aanmaken
Stap 1: Het GTPv2 CSR-pakket komt binnen via de servicepoort op een van de beschikbare SF's. Het wordt in de Rx-wachtrijen van de NIC-serviceinterface geplaatst en opgehaald door een van de PMD-kernen van het iftask-proces. Boxertap zal de MEH-header plaatsen en het pakket wordt via IOMux doorgestuurd naar de lokale vNPU voor het opzoeken van de flow.
Aangezien dit een nieuwe sessie is, heeft de vNPU geen specifieke flow geprogrammeerd voor dit, en het zal moeten routeren het pakket naar de demuxmgr op de demux-kaart.
Stap 2: vNPU verandert de MEH header (met een nieuwe BIA voor het relevante demux proces). IOMUX weet dat het dit via het DI-netwerk naar de demux-kaart moet sturen. Als het taakproces op de Demux-kaart het inkomende pakket verwerkt, zal IOMux het naar de KNI-module leiden (de interface naar de kernel). Door de kernal zal het uiteindelijk in het demuxmgr-proces terechtkomen (in dit geval ettpinmgr).
Stap 3: De Demuxmgr voert zijn taken uit. Selecteer een sessmgr en programmeer npumgr met de stromen voor de volgende GTPv2-pakketten
De vNPU's van alle kaarten kunnen toegang krijgen tot het gedeelde geheugen dat npumgr gebruikt om deze stromen te programmeren.
Stap 4: De GTPv2 CSR wordt nu doorgestuurd naar de geselecteerde sessmgr. Het is MEH wordt opnieuw gewijzigd en doorgestuurd van de Demux-kaart, op het DI-net naar de Sessmgr SF-kaart. Het IOMUX-proces op die kaart stuurt het pakket over de MCDMA-interface naar de geselecteerde sessiemgr. Vanaf hier zal sessmgr al het GTPv2-verkeer voor deze sessie afhandelen. Zodra de GTPU TEID's zijn onderhandeld, zal het de stromen door NPUmgr zodanig programmeren dat daaropvolgende GTPU-pakketten ook rechtstreeks van binnenkomende SF-kaart naar sessmgr SF-kaart kunnen gaan.
vCPU's in iftask
Tijdens de implementatie wordt een bepaalde hoeveelheid virtuele centrale verwerkingseenheden (vCPU's) statisch toegewezen aan het iftask-proces. Dit vermindert het aantal kernen voor userspace-toepassingen (sessmgr etc), maar het verbetert de prestaties van I/O aanzienlijk.
Deze toewijzing gebeurt via onderstaande parameter in de sjabloon param.cfg die tijdens de implementatie aan elke SF/CF is gekoppeld:
- IFTASK_CORES (% van de beschikbare cores die aan iftask moeten worden toegewezen)
- (IFTASK_CRYPTO_CORES - (% van de beschikbare kernen die moeten worden toegewezen voor cryptoverwerking (in het geval van EPDG))
- (IFTASK_MCDMA_CORES - (om verder af te stemmen op het aantal cores dat is toegewezen aan de MCDMA-functionaliteit)
- Op een SF zal het iftask-proces intern de toegewezen cores verdelen in:
- Poll Mode Drivers (PMD) vCPU's (tx/rx/vnpu-activiteit uitvoeren)
- MCDMA vCPU's, die pakketten overbrengen van iftask naar sessmgr en terug
- Op een CF zijn geen MCDMA vCPU's vereist, omdat SF's geen sessiemerprocessen hosten.
De opdracht 'toon cloudhardware als taak' geeft hier meer informatie over bij uw QVPC-DI-implementatie:
[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
Command 'show cloud configuration' geeft meer details over de gebruikte parameters:
[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
Ontwerpoverwegingen:
Er zijn een aantal factoren waarmee rekening moet worden gehouden bij het toewijzen van vCPU's aan iftask.
-totale vCPU's beschikbaar voor de SF vs iftask vCPU's: De standaardconfiguratie specificeert 30% van vCPU's die zijn gekoppeld aan iftask via de IFTASK_CORES-parameter in param.cfg-bestand. Maar dit kan variëren, afhankelijk van de toepassing (MME vs SPGW vs ePDG) -> Te raadplegen met engineering.
-iftask vCPU's toegewezen aan PMD vs iftask vCPU's toegewezen aan MCDMA. Als u wilt controleren of dit in evenwicht is, raadpleegt u het gedeelte over taakprestaties hieronder.
-iftask MCDMA vCPU's vs resterende vCPU's voor alle toepassingen. Meestal is het goed om een 1/x verdeling van iftask MCDMA vCPU's tegen de resterende vCPU's voor de toepassingen (sessmgr / aaamgr /...).
Voorbeeld:
Totaal kernen 38 beschikbaar voor SF:
-14 toegewezen aan iftask (6 PMD, 8 MCDMA)
-24 toegewezen aan andere processen
Dat betekent dat er 1 MCDMA vCPU is voor elke 3 vCPU-toepassingen.
Dit zorgt voor een gelijke belasting voor elke MCDMA vCPU.
Bewaking van taakprestaties
Het iftask proces kan op verschillende manieren worden gecontroleerd.
Consolideer de lijst met show-opdrachten:
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
Command #show cpu info verbose geeft geen informatie over de iftask cores. Ze zullen altijd worden vermeld op 100% gebruik.
In het onderstaande voorbeeld zijn core 1,2,3 geassocieerd met iftask en worden ze vermeld bij 100% gebruik, dit wordt verwacht.
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)Command #show npu utilisatietabel geeft een goede samenvatting van het gebruik van elke kern die is gekoppeld aan het iftask-proces (op elke kaart).
[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%Opdracht #npumgr-gebruiksgegevens tonen (verborgen opdracht)
Deze opdracht geeft meer informatie over elke iftask core, en wat verbruikt CPU op deze kernen.
Zowel PMD- als MCDMA-kernen moeten een redelijk gelijkmatige belasting hebben.
Als dit niet het geval is, kan enige afstemming vereist zijn (bijvoorbeeld meer/minder MDMA-kernen toewijzen).
******** 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: ...Meer uitleg:
De CPU wordt als volgt verantwoord voor een pakket dat binnenkomt op het iftask-proces via de servicepoort of DI-poort.
De Vnpu-lookup is het meest CPU-intensieve onderdeel.
Als na het opzoeken van Vnpu:
-Als het pakket wordt verzonden naar de MCDMA-kern, wordt de CPU-tijd verantwoord op de McDMARx van de relevante MCDMA-kern.
-Als het pakket wordt verzonden naar een andere iftask core, wordt de CPU-tijd verantwoord onder Vnpu
-Als het pakket wordt verzonden op dezelfde taakkern, wordt de CPU-tijd verantwoord onder PortRx
-Als het pakket wordt verzonden op dezelfde taakkern, wordt de CPU-tijd verantwoord onder KniRx
PortRx bevat ook aanzienlijke algemene overhead voor het verwijderen van pakketten uit de ontvangstwachtrijen en het verzenden / in de wachtrij plaatsen naar waar ze naartoe moeten
Opdrachten #show npumgr dinet utilisation pps, #show npumgr dinet utilisation bbps en #show port utilisation table
Ze bieden informatie over de belasting van de DI-poorten en de servicepoorten.
De werkelijke prestaties zijn afhankelijk van de NIC/CPU en de CPU-toewijzing aan 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 0Command #show cloud monitor di-network overzicht
Deze opdracht bewaakt de status van het DI-netwerk. Kaarten sturen hartslagen naar elkaar en het verlies wordt gecontroleerd. In een gezond systeem wordt geen verlies gemeld.
[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%
Opdracht #show iftask stats summary
Bij hogere NPU-belastingen is het mogelijk dat het verkeer wordt weggelaten.
Om dit te evalueren, kan opdracht #show iftask stats summary output worden genomen.
[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 en HW-RSS
RSS is een functie die inkomende verkeer afkomstig van een NIC over meerdere DPDK-processors kan verdelen. Doorgaans ondersteunt de NIC RSS in HW, waardoor het verkeer over meerdere iTask-kernen kan worden verdeeld.
Het iftask-proces in Staros heeft een softwareversie van rss geïmplementeerd die kan worden ingeschakeld als:
-nic ondersteunt geen HWRSS (en dus zal al het tx/rx-verkeer op één iftask CPU terechtkomen).
-NIC heeft niet genoeg tx/rx-wachtrijen (minder wachtrijen dan beschikbare tx/rx CPU's toegewezen aan iftask). In dat geval maakt de SW-RSS (uitgebreid) een goede verdeling over alle beschikbare iftask cores die zijn toegewezen voor rx/tx mogelijk.
Deze functie werkt alleen voor verkeer dat binnenkomt via servicepoorten. Er wordt geen rekening gehouden met het DI-verkeer.
Er bestaan 3 configuratiemodi:
-Geen iftask SW-RSS - SW-RSS uitgeschakeld. Het systeem is gebaseerd op HW RSS.
-iftask SW-RSS Uitgebreid - SW RSS gebruiken voor al het verkeer. SW RSS kan samen met HW RSS worden uitgevoerd. Het is niet nodig om HW RSS uit te schakelen. Maar de SW RSS zal verantwoordelijk zijn voor de feitelijke load balancing van het SERVICE-verkeer naar de iftask cores.
-iftask sw-rss supplemental - sw rss gebruiken voor alleen het verkeer dat niet wordt ondersteund door hw-rss (voorbeeld: MPLS-verkeer)
Met zowel HW als SW RSS is het belangrijk om te begrijpen hoe het verkeer wordt gehasht in de verschillende iftask / dpdk-processors.
HW RSS: hashing is afhankelijk van de hardware. Hieronder volgt een voorbeeld:
[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: Vanaf Staros 21.6 gedraagt de SW RSS-versie hashing zich als volgt:
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
Belangrijk: RSS voor gecodeerd DI-verkeer:
Bij afwezigheid van SW-RSS (aanvullend/uitgebreid) is het mogelijk dat al het versleutelde DI-verkeer wordt gehasht in één Core op iTask.
Dit zal ervoor zorgen dat deze kern consequent een hoger gebruik heeft dan de anderen.
Sinds CSCvi06080 
Dit kan nu worden beperkt door deze configuratieopdracht:
iftask di-net-encrypt-rss
Na integratie van CSCvm41257 Deze optie wordt echter standaard ingesteld.
Meer informatie over SW RSS:
Het doel van sw-rss is om de PMD-kernen te belasten en doorvoerbeperkende scenario's te vermijden waarbij één PMD-kern maximaal presteert wanneer de andere een aanzienlijke beschikbare capaciteit hebben.
Alle toegangspakketten voor servicepoorten worden van de NIC gehaald en voorzien van MEH-inkapseling door de PMD-kern die de Rx-wachtrij bedient waarop ze aankomen.
Op dit punt, als de taak niet weet waar het pakket moet worden verzonden. Pakketten moeten door de VNPU worden verwerkt om de interne bestemming te bepalen. Vrijwel al deze pakketten gaan door IOC / flow-opzoeken wanneer ze worden overgedragen aan VNPU. De uitzonderingen hebben betrekking op teruggooi om redenen zoals ongeconfigureerde / uitgeschakelde vlan of ongeldige MAC-bestemming (er is ook het L3-doorstuurscenario, maar dit is ongebruikelijk).
Als sw-rss niet is geconfigureerd, vindt de VNPU IOC/flow lookup-verwerking op dezelfde kern plaats onmiddellijk na de MEH-vergrendeling. Als sw-rss is geconfigureerd, worden pakketten in de wachtrij geplaatst voor VNPU-verwerking op basis van een hash. De VNPU IOC/flow lookup-operatie is de duurste iftask-functie; sw-rss stelt ons in staat om die werklast over alle PMD-kernen te verdelen.
Na de VNPU IOC/flow lookup wordt het pakket ofwel via DINet-transmissie naar een andere SF verzonden of via MCDMA-overdracht in de wachtrij geplaatst bij de lokale app (nogmaals, er zijn uitzonderingen, maar ik geloof niet dat ze relevant zijn voor deze discussie).
Pakketten die naar een andere SF worden verzonden, worden direct in de wachtrij geplaatst naar het juiste MCDMA-kanaal op de bestemmingskaart na DINet Rx. Hiervoor is geen (tweede) VNPU-pas nodig.
TX/RX-wachtrijen
In de iftask logs kunnen we logs zien zoals:
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
Dit heeft betrekking op het ondersteunde aantal rx- en tx-wachtrijen dat de werkelijke hardware ondersteunt versus het aantal tx / rx-wachtrijen dat als een taak wordt aangevraagd.
Wat als taak verzoeken is nauw verbonden met het aantal processors toegewezen aan iftask.
Let op: iedere bestuurder is anders. Sommige queryhost, sommige hebben hardcoded.
Het aantal hw tx requested is het aantal cores dat dpdk gebruikt. Dit is meestal een meer dan de totale cores toegewezen aan iftask omdat dpdk omvat de kern waarop de controle / ipc thread draait. Deze kern wordt gedeeld met de boxer en gepland als een CPU voor algemene doeleinden (de dpdk-besturings-/ipc-thread gebruikt niet veel CPU).
Het aantal gevraagde hardware is meestal het aantal PMD-cores.
Als taak de min (gevraagde, max) voor elke poort toewijst en deze over de kernen verdeelt. Het distributiealgoritme is een beetje ingewikkeld. Het doel is om de werklast zo gelijkmatig mogelijk over alle kernen te verdelen.
Iftask txbatch
Sinds release 21.9 heeft staros de volgende standaard iftask configuratie-opties die belangrijk zijn voor batching (aggregeren van verkeer). Dit heeft enige negatieve invloed op de prestaties wanneer de node wordt getest met enkele (of enkele) abonnees.
# iftask mcdmatxbatch burst size 32 # iftask mcdmatxbatch latency 200 # iftask txbatch burst size 32 # iftask txbatch latency 200
Meer uitleg hierover staat in een apart artikel:
Bulkstaten
Bulkstat-schema is ontwikkeld voor QPVC-DI-prestaties met betrekking tot iftask / dinet. Dit is handig voor het bewaken van het dinet, de servicepoorten en het gebruik van de NPU vanuit het oogpunt van prestaties en belasting:
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%
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
09-Jun-2018
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)