مراقبة أداء مهام وحدة المعالجة المركزية (IFTASK) وأداء وحدة المعالجة المركزية (NPU) على QvPC-DI
المقدمة
يوضح هذا المستند كيفية مراقبة أداء IFTASK / NPU على QvPC-DI.
كما يوفر مزيدا من المعلومات عن بعض المفاهيم الرئيسية للتقييم.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى QvPC-DI.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
بنية IFTASK
ifTask هي عملية في QvPC-DI. وهو يتيح وظائف مجموعة أدوات تطوير مستوى البيانات (DPDK) على البطاقة الظاهرية (SF) لوظيفة الخدمة والبطاقة الظاهرية (CF) لوظيفة التحكم لمنافذ شبكة DI ومنافذ الخدمة. تعد DPDK طريقة أكثر فعالية لمعالجة الإدخال/الإخراج في البيئات الافتراضية.
يتم الآن نقل برامج تشغيل الأجهزة لوحدات تحكم واجهة الشبكة (NIC) عالية الأداء إلى مساحة المستخدم، والتي تتجنب محولات السياق المكلفة (userSpace/kernelspace).
تعمل برامج التشغيل في الوضع غير القابل للانقطاع في مساحة المستخدم، ولمؤشرات الترابط حق الوصول المباشر إلى قوائم انتظار الأجهزة/المخازن المؤقتة للحلقة في برامج تشغيل NIC هذه.
تتوفر الوثائق الخاصة بالبنية على :
مقدمة عن دليل إدارة نظام النظام الأساسي لبوابة Ultra Gateway.
ترى في هذا الرسم التخطيطي البنية الأساسية للمهام التفصيلية (ل SF):
توجد مكونات مختلفة:
برنامج تشغيل وضع الاستقصاء (PMD): هذه هي الوظيفة التي تقوم بفحص قوائم انتظار الأجهزة بشكل مستمر من قوائم انتظار NIC (في حالة SR-IOV)، أو المخازن المؤقتة لحلقة SW (في حالة نوع الواجهات الظاهرية/vmxnet). ولهذا السبب يتم ربط وحدة المعالجة المركزية (CPU) بأجهزة PMDs هذه باستمرار بنسبة 100٪.
أثناء النشر، يمكن تخصيص وحدات المعالجة المركزية المخصصة لوحدة المعالجة المركزية (CPU) للمهام والوظائف المختلفة داخل IFTASK بشكل ثابت من خلال ملف param.cfg.
الضغط على البوكسر: إرفاق/إزالة بيانات تعريف StarOS (رأس MA) إلى الحزم بناء على المكان الذي تأتي منه الحزمة (مثل: منفذ DI/منفذ الخدمة)، وأين يجب إرساله (مثل: وحدة vNPU محلية)
برنامج IOMUX: تحتوي على مكتبة BIA مع كافة الوجهات (منافذ/منافذ/vNPU/..). هذه الوظيفة أساسا توجه الحزم بناء على BIA الخاص بها
vNPU: -تصنيف/بحث التدفق. ويمكن مقارنة ذلك بوحدة البرامج الوطنية في النظم القائمة على الأجهزة (ASR5000/ASR5500).
لا تزال التدفقات في vNPU مبرمجة من قبل NPUmgr (الذي يحصل على معلوماته من Demuxmgr s/sesmgr وما إلى ذلك) في الذاكرة المشتركة التي يمكن الوصول إليها بواسطة vNPU.
-بالإضافة إلى ذلك، يتم إنشاء واجهة برمجة تطبيقات (API) بحيث يمكن ل npumgr/sesmgr إستطلاع vNPU للإحصاء/التكوين
MCDMA: تتم كتابة الحزم الموجهة إلى Sesmgr إلى واجهة MCDMA (من خلال مراكز/خيوط اتصال MCDMA المختلفة المتوفرة). ويتم بعد ذلك توفير هذه الحزم للتطرق عبر DMA. وهذا يوفر زيادة حقيقية في الأداء حيث أن kernel لا يشارك إلا بشكل محدود. وهذا موضح أكثر في هذه المقالة.
كما يوفر MCDMA إمكانيات الحزم (لمعالجة العديد من الحزم في مكالمة نظام واحدة).
كينيون: واجهة للحزم التي تحتاج أن تتجه إلى نواة لينوكس (DI control/ARP/ICMP/routing/...)
تدفق حزمة IfTask
يشرح المخطط أدناه تدفق الحزمة لحزمة مستوى التحكم. مثال: طلب جلسة عمل إنشاء GTPv2
الخطوة 1: سوف تأتي حزمة GTPv2 CSR من خلال منفذ الخدمة على أي من ملفات SF المتاحة. سيتم وضعها في قوائم انتظار Rx الخاصة ببطاقة واجهة الخدمة NIC، وستلتقط بواسطة أحد مراكز PMD لعملية IFTASK. يضع Boxertap رأس MA، وسيتم إعادة توجيه الحزمة من خلال IOMux إلى vNPU المحلي للبحث عن التدفق.
ونظرا لأن هذه جلسة جديدة، فإن وحدة المعالجة المركزية (vNPU) لا تحتوي على تدفق معين تمت برمجته لهذا الغرض، وسيتعين عليها توجيه الحزمة إلى الأمر demuxmgr على بطاقة demux.
الخطوة 2: تغير vNPU رأس MA (مع BIA جديد لعملية العرض ذات الصلة). يعرف Iomux أن عليه إرسال هذا عبر شبكة DI تجاه بطاقة العرض. وستتولى عملية IFtask على بطاقة Demux الربط الوارد، وستقوم IOMux بتوجيهها إلى وحدة KNI (والتي هي الواجهة باتجاه kernel). من خلال ال kernal سينتهي في نهاية المطاف في عملية demuxmgr (egtpinmgr في هذه الحالة).
الخطوة 3: سيقوم الأمر Demuxmgr بأداء مهامه. حدد جلسة عمل، والبرنامج مع التدفقات لحزم GTPv2 التالية
ستتمكن وحدة vNPU لكافة البطاقات من الوصول إلى الذاكرة المشتركة التي لا تستخدم لبرمجة هذه التدفقات.
الخطوة 4: تتم الآن إعادة توجيه GTPv2 CSR إلى جلسة العمل المحددة. يتم تغييره مرة أخرى، ويتم إعادة توجيهه من بطاقة Demux، على شبكة DI باتجاه بطاقة Sesmgr SF. ستقوم عملية IOMUX على تلك البطاقة بإعادة توجيه الحزمة عبر واجهة MCDMA نحو جلسة العمل المحددة. من هنا فصاعدا، سيقوم الاختبار بمعالجة كافة حركات مرور GTPv2 لجلسة العمل هذه. بمجرد التفاوض على GTPU TEID، فإنه سيقوم ببرمجة التدفقات عبر NPUmgr بحيث يمكن لحزم GTPU اللاحقة أيضا الانتقال مباشرة من بطاقة SF الواردة إلى بطاقة SF الأساسية.
وحدة المعالجة المركزية الافتراضية في حالة المهمة
وخلال النشر، يتم تخصيص كمية معينة من وحدات المعالجة المركزية الافتراضية (vCPU) بشكل ثابت لعملية IFTASK. وهذا يقلل من عدد مراكز التطبيقات الخاصة بمساحة المستخدمين (وغير ذلك)، ولكنه يحسن كثيرا من أداء الإدخال/الإخراج.
يتم هذا التخصيص عبر المعلمة أدناه في قالب param.cfg المقترن بكل SF/CF أثناء النشر:
- IFTASK_CORES (٪ من النوى المتاحة ليتم تعيينها مع IFTASK)
- (IFTASK_CRYPTO_CORES - (٪ من المراكز المتاحة التي سيتم تعيينها لمعالجة التشفير (في حالة EPDG))
- (IFTASK_MCDMA_CORES - (لمزيد من الضبط إلى عدد المراكز المخصصة لوظائف MCDMA)
- على SF، ستقوم عملية IFTASK داخليا بتوزيع النوى المخصصة لها في:
- برامج تشغيل وضع الاستقصاء (PMD) vCPU (القيام بنشاط tx/rx/vnpu)
- MCDMA vCPU، القيام بنقل الحزم من IFTASK إلى SESMGR وإلى الخلف
- في حالة إستخدام CF، لا يلزم إستخدام وحدة المعالجة المركزية MCDMA vCPU، نظرا لأن وحدات المعالجة المركزية (SF) لا تستضيف عمليات الاختبار الذاتي.
يعطي الأمر 'show cloud hardware iftask' المزيد من التفاصيل حول ذلك على نشر 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
سيعطي الأمر show cloud configuration' المزيد من التفاصيل حول المعلمات المستخدمة:
[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
اعتبارات التصميم:
وهناك عدد من العوامل التي يجب أن تؤخذ في الاعتبار عند تخصيص وحدات المعالجة المركزية الافتراضية لإنجاز المهام.
-إجمالي vCPU المتوفر ل SF مقابل IFTASK vCPU: يحدد التكوين الافتراضي 30٪ من vCPU المقترن ب ifTask عبر معلمة IFTASK_CORES في ملف param.cfg. ولكن هذا قد يختلف باختلاف التطبيق (MME مقابل SPGW مقابل ePDG) —> الذي يجب إستشارته مع الهندسة.
-إذا كانت وحدة المعالجة المركزية (vCPU) المخصصة ل PMD مقابل IFTASK vCPU المخصصة ل MCDMA. للتحقق مما إذا كان هذا متوازنا، الرجاء مراجعة قسم أداء IfTask أدناه.
-تنفيذ مهام وحدة المعالجة المركزية (vCPU) الخاصة بوحدة المعالجة المركزية (MCDMA) مقابل وحدات المعالجة المركزية (vCPU) المتبقية لجميع التطبيقات. وعادة ما يكون من الجيد أن يكون لديك توزيع 1/x من IFTASK MCDMA vCPU مقابل وحدات vCPU المتبقية للتطبيقات (sesmgr/aamgr/...).
مثال:
إجمالي المراكز 38 المتوفرة ل SF:
-14 تم تعيينها إلى Iftask (6 PMD، 8 MCDMA)
-ترك 24 مكلفا بعمليات أخرى
مما يعني وجود وحدة معالجة مركزية واحدة MCDMA vCPU لكل 3 تطبيقات خاصة بوحدة المعالجة المركزية.
يساعد ذلك على ضمان التحميل المتساوي لكل وحدة معالجة مركزية (CPU) خاصة بإدارة قاعدة بيانات إدارة التهيئة (MCDMA).
مراقبة أداء المهمة
يمكن مراقبة عملية ifTask بعدة طرق.
دمج قائمة أوامر 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
لن يعطي الأمر #show معلومات وحدة المعالجة المركزية معلومات حول مراكز IFTASK. سيتم إدراجها دائما بنسبة إستخدام 100٪.
في المثال التالي، تم ربط core 1،2،3 ب ifTask، وتم إدراجه عند نسبة إستخدام 100٪، وهذا متوقع.
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)سيعطي الأمر #show npu use table ملخصا جيدا حول إستخدام كل مركز مرتبط بعملية ifTask (في كل بطاقة).
[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%الأمر #show npumgr use information (أمر مخفي)
يوفر هذا الأمر المزيد من المعلومات حول كل نواة Iftask، وما الذي يستهلك وحدة المعالجة المركزية (CPU) في هذه المراكز.
يجب أن يكون لكل من مركزي PMD و MCDMA حمل متساو إلى حد ما.
وإذا لم يكن الأمر كذلك، فقد يلزم إجراء بعض عمليات الضبط (تخصيص المزيد/الأقل من مراكز MDMA على سبيل المثال).
******** 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: ...المزيد من التوضيح:
يتم حساب وحدة المعالجة المركزية كما يلي للحزمة الواردة في عملية الاختبار عبر منفذ الخدمة أو منفذ DI.
يعد بحث VNPU هو الجزء الأكثر كثافة من وحدة المعالجة المركزية.
إذا كنت بعد بحث VNPU:
-يتم إرسال الحزمة إلى مركز MCDMA، وسيتم حساب وقت وحدة المعالجة المركزية (CPU) في McdmaRx الخاص بنواة MCDMA ذات الصلة.
-يتم إرسال الحزمة إلى مركز بحث إجرائي آخر، وسيتم حساب وقت وحدة المعالجة المركزية (CPU) ضمن Vnpu
-يتم إرسال الحزمة إلى نفس مركز المهمة، وسيتم حساب وقت وحدة المعالجة المركزية تحت PortRx
-يتم إرسال الحزمة في نفس مركز المهمة، وسيتم حساب وقت وحدة المعالجة المركزية تحت KniRx
يتضمن PortRx أيضا مصاريف عامة كبيرة لسحب الحزم من قوائم انتظار الاستقبال وإرسالها/وضعها في قائمة الانتظار إلى حيث تحتاج إلى الذهاب
الأوامر #show npumgr Service use pps، و#show #show npumgr Service use bbps وجدول إستخدام المنافذ
هم يزودون معلومة حول الحمل على ال di ميناء، والخدمات ميناء.
يعتمد الأداء الفعلي على تخصيص NIC/CPU ووحدة المعالجة المركزية (CPU) لكل مهمة.
[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 0الأمر #show cloud monitor di-network summary
يراقب هذا أمر صحة شبكة DI. ترسل البطاقات نبضات القلب لبعضها البعض، وترصد الخسارة. وفي النظام الصحي، لا يبلغ عن أي خسارة.
[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%
الأمر #show ifTaskStats summary
مع حمولات وحدة المعالجة المركزية (NPU) الأعلى، قد يكون من الممكن إسقاط حركة مرور البيانات.
لتقييم ذلك، يمكن أخذ الأمر #show ifTaskStats summary.
[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 و HW-RSS
RSS هو ميزة يمكنها توزيع حركة المرور الواردة من بطاقة واجهة الشبكة (NIC) عبر معالجات DPDK المتعددة. عادة ما تدعم بطاقة واجهة الشبكة (NIC) برنامج RSS في الأجهزة، مما يتيح لها توزيع حركة مرور البيانات عبر مراكز متعددة للمهام.
قامت عملية ifTask في Staros بتنفيذ إصدار برنامج من RSS يمكن تمكينه إذا:
-لا تدعم بطاقة واجهة الشبكة (NIC) نظام HW RSS (وبالتالي فإن جميع حركة مرور tx/rx ستنزل على وحدة معالجة مركزية (CPU) واحدة لكل مهمة).
-لا تحتوي بطاقة واجهة الشبكة (NIC) على قوائم انتظار tx/rx كافية (قوائم انتظار أقل من قوائم الانتظار المتوفرة التي تم تعيين وحدة المعالجة المركزية tx/rx لها لتنفيذ المهمة). وفي هذه الحالة، يتيح المحول SW-RSS (الشامل) إمكانية التوزيع المناسب عبر جميع مراكز المهام المتوفرة المخصصة ل rx/tx.
تعمل هذه الميزة فقط لحركة المرور الواردة من خلال منافذ الخدمة. لم يتم أخذ حركة مرور DI في الاعتبار.
توجد 3 أوضاع تكوين:
-لا يوجد حالة SW-RSS - تم تعطيل SW-RSS. يعتمد النظام على RSS للأجهزة.
-إذا كانت مهمة sw-rss شاملة - إستخدام sw rss لجميع حركة المرور. يمكن تشغيل RSS ل SW مع RSS للأجهزة. لا حاجة إلى تعطيل RSS للالأجهزة. ولكن سيكون SW RSS مسؤولا عن موازنة حمل حركة مرور الخدمة الفعلية إلى مراكز العمليات.
-ifTask sw-rss المكمل - إستخدام SW RSS لحركة المرور التي لا تدعمها HW-RSS (مثال: حركة مرور MPLS)
مع كل من HW و SW RSS، من المهم فهم كيفية تجزئة حركة مرور البيانات إلى مختلف معالجات iftask/dpdk.
الخادم طراز RSS: التجزئة تعتمد على العتاد. فيما يلي مثال:
[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: بدءا من Staros 21.6، يتصرف إصدار SW RSS بهذا الشكل:
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
هام: RSS لحركة مرور DI المشفرة:
في غياب SW-RSS (تكميلي/شامل)، قد يكون من الممكن تجزئة جميع حركة مرور بيانات DI المشفرة إلى مركز واحد في أي مهمة.
سيؤدي ذلك إلى إستخدام هذا الأساس بشكل متناسق بمعدل أعلى من غيره.
منذ CSCvi06080 
، يمكن الآن الحد من هذا الإجراء باستخدام أمر التكوين هذا:
iftask di-net-encrypt-rss
بعد دمج CSCvm41257 ، سيتم جعل هذا الخيار افتراضيا.
مزيد من المعلومات التفصيلية حول SW RSS:
والغرض من إستراتيجية الحد من الفقر هو موازنة أحمال مراكز PMD وتجنب سيناريوهات الحد من سعة المعالجة عندما يستوعب أحد النواة لبروتوكول PMD الآخر سعة متوفرة كبيرة.
يتم سحب جميع حزم مدخل الخدمة من NIC ويتم تضمين MA بواسطة نواة PMD التي تخدم قائمة انتظار Rx التي تصل إليها.
عند هذه النقطة، لا تعرف المهمة أين ترسل الحزمة. يجب معالجة الحزم بواسطة VNPU لتحديد الوجهة الداخلية. فعليا تمر جميع هذه الحزم من خلال البحث في IOC/التدفق عندما يتم تسليمها إلى VNPU. وتتصل الاستثناءات بالمرتجعات لأسباب مثل شبكة VLAN غير المكونة/المعطلة أو MAC الوجهة غير الصالحة (هناك أيضا سيناريو إعادة توجيه L3، ولكن هذا غير شائع).
إذا لم يتم تكوين SW-RSS، تحدث معالجة بحث VNPU IOC/Flow على نفس المركز مباشرة بعد IMA Encap. إذا تم تكوين SW-RSS، يتم وضع الحزم في قائمة الانتظار إلى مركز لمعالجة VNPU استنادا إلى تجزئة. تعد عملية بحث VNPU IOC/Flow الوظيفة الفردية الأكثر تكلفة للمهام؛ يتيح لنا SW-RSS موازنة حمل العمل هذا عبر جميع مراكز PMD.
بعد بحث VNPU IOC/التدفق، فإن الحزمة إما يتم إرسالها إلى SF آخر عبر DINet إرسال أو وضعها في قائمة الانتظار إلى تطبيق محلي عبر نقل MCDMA (مرة أخرى، هناك إستثناءات، ولكن لا أعتقد أنها ذات صلة بهذه المناقشة).
يتم وضع الحزم المرسلة إلى SF آخر في قائمة الانتظار مباشرة إلى قناة MCDMA المناسبة على بطاقة الوجهة بعد DINet Rx. لا تتطلب هذه الوحدات مرور (ثان) VNPU.
قوائم انتظار Tx/RX
في سجلات IfTask، يمكن أن نرى سجلات مثل:
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
وهذا يتعلق بعدد قوائم انتظار RX و tx المدعومة التي يدعمها الجهاز الفعلي مقابل عدد قوائم انتظار tx/rx التي تلبي طلبات المهام.
يرتبط ما تطلبه IfTask إرتباطا وثيقا بعدد المعالجات المخصصة ل IfTask.
ملاحظة: كل سائق مختلف. بعض مضيف الاستعلام، البعض قد تم ترميزه.
يقصد ب Hw tx Requested Count عدد النوى التي تستخدمها DPDK. عادة ما يكون هذا العدد أكبر من إجمالي المراكز المخصصة لتنفيذ المهمة لأن DPDK تتضمن الأساس الذي يتم تشغيل مؤشر ترابط عنصر التحكم/IPC عليه. تتم مشاركة هذا الأساس مع الملاكم وجدولته كوحدة معالجة مركزية للأغراض العامة (لا يستخدم مؤشر ترابط عنصر تحكم DPDK/IPC الكثير من وحدة المعالجة المركزية).
وعادة ما يكون العدد المطلوب ل HW rx هو عدد مراكز PMD.
إذا كانت المهمة تقوم بتخصيص الحد الأدنى (المطلوب، الحد الأقصى) لكل منفذ وتوزيعهم عبر المراكز. خوارزمية التوزيع معقدة قليلا. الهدف هو توزيع حمل العمل بالتساوي قدر الإمكان عبر جميع النوى.
IfTask txbatch
منذ الإصدار 21.9، يتلقى STAROS خيارات تكوين المهمة الافتراضية التالية المهمة للتجميع (تجميع حركة المرور). وهذا يؤثر بشكل سلبي على الأداء عندما تكون العقدة قيد الاختبار باستخدام مشتركين فرديين (أو عدد قليل).
# iftask mcdmatxbatch burst size 32 # iftask mcdmatxbatch latency 200 # iftask txbatch burst size 32 # iftask txbatch latency 200
المزيد من التوضيح حول هذا الموضوع يكون في وثيقة منفصلة:
بقطات
تم تطوير مخطط BulkStat لأداء QPVC-DI المرتبط ب IFTASK/Dinet. وهذا مفيد لمراقبة الطراز ومنافذ الخدمة واستخدام وحدة المعالجة المركزية (NPU) من منظور الأداء/الحمل:
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%
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
09-Jun-2018
|
الإصدار الأولي |
التعليقات