diff options
Diffstat (limited to 'docs')
28 files changed, 3876 insertions, 4714 deletions
diff --git a/docs/content/_index.md b/docs/content/_index.md index f2736d5a57..1caa6b2932 100644 --- a/docs/content/_index.md +++ b/docs/content/_index.md @@ -46,4 +46,12 @@ type: "docs" packet path thru server SUTs, three distinct logical topology types are used for VPP DUT data plane testing. - **[VPP Startup Settings]({{< relref "/infrastructure/vpp_startup_settings" >}})**: - List of common settings applied to all tests and test dependent settings.
\ No newline at end of file + List of common settings applied to all tests and test dependent settings. +5. [PERFORMANCE DASHBOARD]({{< dashboard_url >}}) + - **[Performance Trending]({{< dashboard_url >}}trending)** + - **[Per Release Performance]({{< dashboard_url >}}report)** + - **[Per Release Performance Comparisons]({{< dashboard_url >}}comparisons)** + - **[Per Release Coverage Data]({{< dashboard_url >}}coverage)** + - **[Test Jobs Statistics]({{< dashboard_url >}}stats)** + - **[Failures and Anomalies]({{< dashboard_url >}}news)** + - **[Search Tests]({{< dashboard_url >}}search)**
\ No newline at end of file diff --git a/docs/content/dashboard/_index.md b/docs/content/dashboard/_index.md new file mode 100644 index 0000000000..fac194db60 --- /dev/null +++ b/docs/content/dashboard/_index.md @@ -0,0 +1,15 @@ +--- +bookCollapseSection: false +bookFlatSection: true +title: "Performance Dashboard" +weight: 5 +--- + +# [Performance Dashboard]({{< dashboard_url >}}) +- **[Performance Trending]({{< dashboard_url >}}trending)** +- **[Per Release Performance]({{< dashboard_url >}}report)** +- **[Per Release Performance Comparisons]({{< dashboard_url >}}comparisons)** +- **[Per Release Coverage Data]({{< dashboard_url >}}coverage)** +- **[Test Jobs Statistics]({{< dashboard_url >}}stats)** +- **[Failures and Anomalies]({{< dashboard_url >}}news)** +- **[Search Tests]({{< dashboard_url >}}search)** diff --git a/docs/content/infrastructure/fdio_csit_testbed_versioning.md b/docs/content/infrastructure/fdio_csit_testbed_versioning.md index 7f6cdfc51c..2e0596e935 100644 --- a/docs/content/infrastructure/fdio_csit_testbed_versioning.md +++ b/docs/content/infrastructure/fdio_csit_testbed_versioning.md @@ -36,6 +36,10 @@ environment versioning include: Following is the list of CSIT versions to date: +- Ver. 15 associated with CSIT rls2406 branch ( + [HW](https://git.fd.io/csit/tree/docs/content/infrastructure/testbed_configuration?h=rls2406), + [CSIT](https://git.fd.io/csit/tree/?h=rls2406) + ). - Ver. 14 associated with CSIT rls2402 branch ( [HW](https://git.fd.io/csit/tree/docs/content/infrastructure/testbed_configuration?h=rls2402), [CSIT](https://git.fd.io/csit/tree/?h=rls2402) diff --git a/docs/content/infrastructure/fdio_dc_testbed_specifications.md b/docs/content/infrastructure/fdio_dc_testbed_specifications.md index da71124078..cda2ff1624 100644 --- a/docs/content/infrastructure/fdio_dc_testbed_specifications.md +++ b/docs/content/infrastructure/fdio_dc_testbed_specifications.md @@ -39,32 +39,22 @@ To access these hosts, VPN connection is required. ### Summary List ``` - #. Type Purpose SUT TG #TB #SUT #TG #skx #ps1 #rng #tx2 #tsh #alt #clx #zn2 #icx #snr #spr #icxd - 1. 1-Node-Skylake nomad skx na 5 5 0 5 0 0 0 0 0 0 0 0 0 0 0 - 2. 1-Node-Cascadelake nomad clx na 4 4 0 0 0 0 0 0 0 4 0 0 0 0 0 - 3. 1-Node-AmpereAltra nomad alt na 4 4 0 0 0 0 0 0 4 0 0 0 0 0 0 - 4. 2-Node-IxiaPS1L47 tcp skx ps1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 - 5. 2-Node-Cascadelake perf clx clx 3 3 3 0 0 0 0 0 0 6 0 0 0 0 0 - 6. 2-Node-ThunderX2 perf tx2 skx 1 1 .5 .5 0 0 1 0 0 0 0 0 0 0 0 - 7. 2-Node-Icelake perf icx icx 4 4 4 0 0 0 0 0 0 0 0 8 0 0 0 - 8. 3-Node-Rangeley perf rng skx 1 3 1 0 0 2 0 0 0 0 0 0 0 0 0 - 9. 3-Node-Taishan perf tsh skx 1 2 .5 .5 0 0 0 2 0 0 0 0 0 0 0 -10. 3-Node-Altra perf alt icx 1 2 1 0 0 0 0 0 2 0 0 1 0 0 0 -11. 2-Node-Zen2 perf zn2 zn2 1 1 1 0 0 0 0 0 0 0 2 0 0 0 0 -12. 3-Node-Icelake perf icx icx 2 4 2 0 0 0 0 0 0 0 0 6 0 0 0 -13. 3-Node-SnowRidge perf snr icx 1 2 .5 0 0 0 0 0 0 0 0 .5 2 0 0 -14. 2-Node-SapphireRapids perf spr spr 4 4 4 0 0 0 0 0 0 0 0 0 0 8 0 -15. 1-Node-SapphireRapids nomad spr na 4 4 0 0 0 0 0 0 0 0 0 0 0 4 0 -16. 3-Node-IcelakeD perf icxd icx 4 6 1 0 0 0 0 0 0 0 0 1 0 0 4 - Totals: 39 48 19.5 7 1 2 1 2 6 10 2 16.5 2 12 4 + #. Type Purpose SUT TG #TB #SUT #TG #skx #ps1 #rng #tx2 #tsh #alt #clx #zn2 #icx #snr #spr #icxd #grc + 1. 1-Node-Skylake nomad skx na 2 2 0 2 0 0 0 0 0 0 0 0 0 0 0 0 + 2. 1-Node-Cascadelake nomad clx na 4 4 0 0 0 0 0 0 0 4 0 0 0 0 0 0 + 3. 1-Node-AmpereAltra nomad alt na 4 4 0 0 0 0 0 0 4 0 0 0 0 0 0 0 + 4. 1-Node-SapphireRapids nomad spr na 4 4 0 0 0 0 0 0 0 0 0 0 0 4 0 0 + 6. 2-Node-Icelake perf icx icx 3 3 3 0 0 0 0 0 0 0 0 6 0 0 0 0 + 7. 2-Node-Octeon perf icx icx 1 1 1 0 0 0 0 0 0 0 0 2 0 0 0 0 + 8. 2-Node-Zen2 perf zn2 zn2 1 1 1 0 0 0 0 0 0 0 2 0 0 0 0 0 + 9. 3-Node-Altra perf alt icx 1 2 1 0 0 0 0 0 2 0 0 1 0 0 0 0 +10. 3-Node-Icelake perf icx icx 2 4 2 0 0 0 0 0 0 0 0 6 0 0 0 0 +11. 3-Node-SnowRidge perf snr icx 1 2 .5 0 0 0 0 0 0 .5 0 0 2 0 0 0 +12. 2-Node-SapphireRapids perf spr spr 4 4 4 0 0 0 0 0 0 0 0 0 0 8 0 0 +13. 3-Node-IcelakeD perf icxd icx 2 4 1 0 0 0 0 0 0 0 0 1 0 0 4 0 +14. 2-Node-Grace perf grc icx 1 1 1 0 0 0 0 0 0 0 0 1 0 0 0 1 ``` -### 1-Node-Skylake Xeon Intel (1n-skx) - -Each 1-Node-Skylake testbed includes one SUT (Server-Type-B2) with NIC -ports connected back-to-back ([Server Types](#server-types)). -Used for FD.io VPP_Device functional driver tests. - ### 1-Node-Altra Arm Ampere (1n-alt) Each 1-Node-Altra testbed includes one SUT (Server-Type-E25) with NIC @@ -77,20 +67,6 @@ Each 1-Node-SapphireRapids testbed includes one SUT (Server-Type-H7) with NIC ports connected back-to-back ([Server Types](#server-types)). Used for FD.io VPP_Device functional driver tests. -### 2-Node-IxiaPS1L47 Ixia PSOne L47 (2n-ps1) - -Each 2-Node-IxiaPS1L47 testbed includes one SUT (Server-Type-B1) and one -TG (Ixia PSOne appliance) with 10GE interfaces connected in a 2-node -circular topology ([Server Types](#server-types)). -Used for FD.io TCP/IP and HTTP performance tests. - -### 2-Node-Cascadelake Xeon Intel (2n-clx) - -Each 2-Node-Cascadelake testbed includes one SUT (Server-Type-C2) and -one TG (Server-Type-C3) connected in a 2-node circular topology -([Server Types](#server-types)). -Used for FD.io performance tests. - ### 2-Node-Zen2 EPYC AMD (2n-zn2) Each 2-Node-Zen2 testbed includes one SUT (Server-Type-D1) and @@ -98,13 +74,6 @@ one TG (Server-Type-D2) connected in a 2-node circular topology ([Server Types](#server-types)). Used for FD.io performance tests. -### 2-Node-ThunderX2 Arm Marvell (2x-tx2) - -Each 2-Node-ThunderX2 testbed includes one SUT (Server-Type-E22) and -one TG (Server-Type-E31) connected in a 2-node circular topology -([Server Types](#server-types)). -Used for FD.io performance tests. - ### 2-Node-Icelake Xeon Intel (2n-icx) Each 2-Node-Icelake testbed includes one SUT (Server-Type-F1) and @@ -112,17 +81,17 @@ one TG (Server-Type-F2) connected in a 2-node circular topology ([Server Types](#server-types)). Used for FD.io performance tests. -### 3-Node-Rangeley Atom Testbeds +### 2-Node-Icelake Xeon Intel (2n-oct) -Each 3-Node-Rangeley testbed includes two SUTs (Server-Type-B5) and one -TG (Server-Type-2) connected in a 3-node circular topology +Each 2-Node-Icelake testbed includes one SUT (Server-Type-XX) and +one TG (Server-Type-XX) connected in a 2-node circular topology ([Server Types](#server-types)). Used for FD.io performance tests. -### 3-Node-TaiShan Arm Huawei (3n-tsh) +### 2-Node-Grace Server Nvidia (2n-grc) -Each 3-Node-TaiShan testbed includes two SUTs (Server-Type-E21) and one -TG (Server-Type-E31) connected in a 3-node circular topology +Each 2-Node-Grace testbed includes one SUT (Server-Type-XX) and +one TG (Server-Type-F6) connected in a 2-node circular topology ([Server Types](#server-types)). Used for FD.io performance tests. @@ -185,7 +154,7 @@ connectivity and wiring across defined CSIT testbeds: FD.io CSIT lab contains following server types: -1. **Server-Type-B1**: Purpose - Skylake Xeon hosts for FD.io builds and data processing. +1. **Server-Type-B1**: Purpose - Skylake Xeon hosts for FD.io builds and data processing (BUILDER). - Quantity: 2 - Physical connectivity: - IPMI and host management ports. @@ -205,52 +174,10 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -2. **Server-Type-B2**: Purpose - Skylake Xeon SUT for FD.io VPP_Device functional tests. - - Quantity: 2. - - Physical connectivity: - - IPMI and host management ports. - - NIC ports connected into 1-node topologies. - - Main HW configuration: - - Chassis: SuperMicro SYS-7049GP-TRT. - - Motherboard: SuperMicro X11DPG-QT. - - Processors: 2* Intel Platinum 8180 2.5 GHz. - - RAM Memory: 16* 16GB DDR4-2666MHz. - - Disks: 2* 1.6TB 6G SATA SSD. - - NICs configuration: - - Numa0: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot2 18:00.xx: x710-4p10GE Intel. - - PCIe Slot4 3b:00.xx: x710-4p10GE Intel. - - PCIe Slot9 5e:00.xx: empty. - - Numa1: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot6 86:00.xx: e810-2CQDA2-2p100GE Intel. - - PCIe Slot8 af:00.xx: e810-2CQDA2-2p100GE Intel. - - PCIe Slot10 d8:00.xx: empty. - -3. **Server-Type-B7**: Purpose - Ixia PerfectStorm One Appliance TG for FD.io TCP/IP performance tests. - - Quantity: 1. - - Physical connectivity: - - Host management interface: 10/100/1000-BaseT. - - 8-port 10GE SFP+ integrated NIC. - - Main HW configuration: - - Chassis: PS10GE4NG. - - Motherboard: SuperMicro X11DPG-QT. - - Processors: Quad-Core, Intel Processor. - - HW accelerators: FPGA offload. - - RAM Memory: 64GB. - - Disks: 1 * 1 TB, Enterprise Class, High MTBF. - - Physical Interfaces: 4 * 10GE SFP+. - - Operating System: Native IxOS. - - Interface configuration: - - Port-1: 10GE SFP+. - - Port-2: 10GE SFP+. - - Port-3: 10GE SFP+. - - Port-4: 10GE SFP+. - -4. **Server-Type-B8**: Purpose - Skylake Xeon SUT for TCP/IP host stack tests. - - Quantity: 1. +1. **Server-Type-B2**: Purpose - Skylake Xeon hosts for FD.io builds and data processing (HST). + - Quantity: 2 - Physical connectivity: - IPMI and host management ports. - - NIC ports. - Main HW configuration: - Chassis: SuperMicro SYS-7049GP-TRT. - Motherboard: SuperMicro X11DPG-QT. @@ -259,40 +186,19 @@ FD.io CSIT lab contains following server types: - Disks: 2* 1.6TB 6G SATA SSD. - NICs configuration: - Numa0: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot2 18:00.xx: x710-4p10GE Intel. - - PCIe Slot4 3b:00.xx: empty. + - PCIe Slot2 18:00.xx: e810-2p100GE Intel. + - PCIe Slot4 3b:00.xx: e810-2p100GE Intel. - PCIe Slot9 5e:00.xx: empty. - Numa1: (x16, x16, x16 PCIe3.0 lanes) - PCIe Slot6 86:00.xx: empty. - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -5. **Server-Type-C2**: Purpose - Cascadelake Xeon SUT for FD.io performance testing. - - Quantity: 3 - - Physical connectivity: - - IPMI and host management ports. - - NIC ports connected into 2-node testbed topologies. - - Main HW configuration: - - Chassis: SuperMicro SYS-7049GP-TRT. - - Motherboard: SuperMicro X11DPG-QT. - - Processors: 2* Intel Gold 6252N 2.3 GHz. - - RAM Memory: 12* 16GB DDR4-2933. - - Disks: 2* 1.92TB SATA SSD. - - NICs configuration: - - Numa0: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot2 18:00.xx: x710-4p10GE Intel. - - PCIe Slot4 3b:00.xx: xxv710-DA2-2p25GE Intel. - - PCIe Slot9 5e:00.xx: ConnectX5-2p100GE Mellanox. - - Numa1: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot6 86:00.xx: e810-2p100GE Intel. - - PCIe Slot8 af:00.xx: empty. - - PCIe Slot10 d8:00.xx: empty. - -6. **Server-Type-C3**: Purpose - Cascadelake Xeon TG for FD.io performance testing. - - Quantity: 3. +2. **Server-Type-C2**: Purpose - Cascadelake Xeon Shared TG for FD.io performance testing. + - Quantity: 1. - Physical connectivity: - IPMI and host management ports. - - NIC ports connected into 2-node testbed topologies. + - NIC ports connected into 3-node testbed topologies. - Main HW configuration: - Chassis: SuperMicro SYS-7049GP-TRT. - Motherboard: SuperMicro X11DPG-QT. @@ -300,16 +206,16 @@ FD.io CSIT lab contains following server types: - RAM Memory: 12* 16GB DDR4-2933. - Disks: 2* 1.92TB SATA SSD. - NICs configuration: - - Numa0: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot2 18:00.xx: x710-4p10GE Intel. - - PCIe Slot4 3b:00.xx: xxv710-DA2 2p25GE Intel. - - PCIe Slot9 5e:00.xx: ConnectX5-2p100GE Mellanox. - - Numa1: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot6 86:00.xx: ConnectX5-2p100GE Mellanox. - - PCIe Slot8 af:00.xx: ConnectX5-2p100GE Mellanox. + - Numa0: (x16, x16, x16 PCIe4.0 lanes) + - PCIe Slot2 18:00.xx: xxv710-DA2-2p25GE Intel. + - PCIe Slot4 31:00.xx: empty. + - PCIe Slot9 5e:00.xx: e810-2CQDA2-2p100GE Intel. + - Numa1: (x16, x16, x16 PCIe4.0 lanes) + - PCIe Slot6 86:00.xx: e810-XXVDA4-4p25GE Intel. + - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -7. **Server-Type-C4**: Purpose - Cascadelake Xeon Backend hosts for FD.io builds and data processing. +3. **Server-Type-C3**: Purpose - Cascadelake Xeon Backend hosts for FD.io builds and data processing. - Quantity: 4. - Physical connectivity: - IPMI and host management ports. @@ -330,7 +236,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -8. **Server-Type-D1**: Purpose - Zen2 EPYC SUT for FD.io performance testing. +4. **Server-Type-D1**: Purpose - Zen2 EPYC SUT for FD.io performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -346,7 +252,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot2 41:00.xx: xxv710-da2-2p25GE Intel. - PCIe Slot3 81:00.xx: mcx556a-edat ConnectX5-2p100GE Mellanox. -9. **Server-Type-D2**: Purpose - Zen2 EPYC TG for FD.io performance testing. +5. **Server-Type-D2**: Purpose - Zen2 EPYC TG for FD.io performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -362,38 +268,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot2 41:00.xx: x710-4p10GE Intel. - PCIe Slot3 81:00.xx: xxv710-da2 2p25GE Intel. -10. **Server-Type-E21**: Purpose - TaiShan Arm Huawei SUT for FD.io performance testing. - - Quantity: 2. - - Physical connectivity: - - IPMI(?) and host management ports. - - NIC ports connected into 3-node topology. - - Main HW configuration: - - Chassis: Huawei TaiShan 2280. - - Processors: 2* hip07-d05 ~ 32* Arm Cortex-A72 - - RAM Memory: 8* 16GB DDR4-2400MT/s - - Disks: 1* 4TB SATA HDD - - NICs configuration: - - PCIe Slot4 e9:00.xx: connectx4-2p25GE Mellanox. - - PCIe Slot6 11:00.xx: x520-2p10GE Intel. - -11. **Server-Type-E22**: Purpose - ThunderX2 Arm Marvell SUT for FD.io performance testing. - - Quantity: 1. - - Physical connectivity: - - IPMI and host management ports. - - NIC ports connected into 2-node topologies. - - Main HW configuration: - - Chassis: Gigabyte R181-T90 1U - - Motherboard: MT91-FS1 - - Processors: 2* ThunderX2 ARMv8 CN9975 2.0 GHz - - RAM Memory: 4* 32GB RDIMM - - Disks: 1* 480GB SSD Micron, 1* 1000GB HDD Seagate_25 - - NICs configuration: - - Numa0: - - no cards - - Numa1: - - PCIe Slot18 91:00.xx: XL710-QDA2-2p40GE Intel. - -12. **Server-Type-E23**: Purpose - Altra Arm Ampere SUT for FD.io performance testing. +6. **Server-Type-E23**: Purpose - Altra Arm Ampere SUT for FD.io performance testing. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -412,7 +287,7 @@ FD.io CSIT lab contains following server types: - Numa1: - no cards. -13. **Server-Type-E24**: Purpose - Altra Arm Ampere for FD.io build. +7. **Server-Type-E24**: Purpose - Altra Arm Ampere for FD.io build. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -424,7 +299,7 @@ FD.io CSIT lab contains following server types: - RAM Memory: 12* 16GB DDR4-3200MT/s - Disks: 1* 960GB SSD Samsung M.2 NVMe PM983 -14. **Server-Type-E25**: Purpose - Altra Arm Ampere SUT for FD.io VPP_Device functional tests. +8. **Server-Type-E25**: Purpose - Altra Arm Ampere SUT for FD.io VPP_Device functional tests. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -445,28 +320,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot3 0003:02:00.xx: XL710-QDA2-2p40GE Intel. - PCIe Slot5 0005:02:00.xx: ConnectX5-2p10/25GE Mellanox. -15. **Server-Type-E31**: Purpose - Skylake Xeon Shared TG for FD.io performance testing. - - Quantity: 1. - - Physical connectivity: - - IPMI and host management ports. - - NIC ports connected into 2-node and 3-node topologies. - - Main HW configuration: - - Chassis: SuperMicro SYS-7049GP-TRT. - - Motherboard: SuperMicro X11DPG-QT. - - Processors: 2* Intel Platinum 8180 2.5 GHz. - - RAM Memory: 16* 16GB DDR4-2666MHz. - - Disks: 2* 1.6TB 6G SATA SSD. - - NICs configuration: - - Numa0: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot2 18:00.xx: x710-4p10GE Intel. - - PCIe Slot4 3b:00.xx: xxv710-DA2 2p25GE Intel. - - PCIe Slot9 5e:00.xx: empty. - - Numa1: (x16, x16, x16 PCIe3.0 lanes) - - PCIe Slot6 86:00.xx: empty. - - PCIe Slot8 af:00.xx: xl710-QDA2-2p40GE Intel. - - PCIe Slot10 d8:00.xx: x710-4p10GE Intel. - -16. **Server-Type-E32**: Purpose - Icelake Xeon Shared TG for FD.io performance testing. +9. **Server-Type-E32**: Purpose - Icelake Xeon Shared TG for FD.io performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -487,7 +341,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 b1:00.xx: e810-2CQDA2-2p100GE Intel. - PCIe Slot10 ff:00.xx: empty. -17. **Server-Type-F1**: Purpose - Icelake Xeon SUT for FD.io performance testing. +10. **Server-Type-F1**: Purpose - Icelake Xeon SUT for FD.io performance testing. - Quantity: 4. - Physical connectivity: - IPMI and host management ports. @@ -508,7 +362,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: ConnectX7-2p200GE Mellanox. - PCIe Slot10 d8:00.xx: empty. -18. **Server-Type-F2**: Purpose - Icelake Xeon TG for FD.io performance testing. +11. **Server-Type-F2**: Purpose - Icelake Xeon TG for FD.io performance testing. - Quantity: 4. - Physical connectivity: - IPMI and host management ports. @@ -529,7 +383,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: ConnectX7-2p200GE Mellanox. - PCIe Slot10 d8:00.xx: empty. -19. **Server-Type-F3**: Purpose - Icelake Xeon TG or SUT for FD.io performance testing. +12. **Server-Type-F3**: Purpose - Icelake Xeon TG or SUT for FD.io performance testing. - Quantity: 6. - Physical connectivity: - IPMI and host management ports. @@ -550,7 +404,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -20. **Server-Type-F4**: Purpose - Icelake Xeon TG for FD.io performance testing. +13. **Server-Type-F4**: Purpose - Icelake Xeon TG for FD.io performance testing. - Quantity: 3. - Physical connectivity: - IPMI and host management ports. @@ -571,7 +425,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 af:00.xx: empty. - PCIe Slot10 d8:00.xx: empty. -21. **Server-Type-F5**: Purpose - Icelake Xeon Shared TG for FD.io performance testing. +14. **Server-Type-F5**: Purpose - Icelake Xeon Shared TG for FD.io performance testing. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -592,7 +446,28 @@ FD.io CSIT lab contains following server types: - PCIe Slot8 b1:00.xx: e810-2CQDA2-2p100GE Intel. - PCIe Slot10 ff:00.xx: empty. -22. **Server-Type-G1**: Purpose - SnowRidge Atom SUT for FD.io performance testing. +15. **Server-Type-F6**: Purpose - Icelake Xeon TG for FD.io performance testing. + - Quantity: 1. + - Physical connectivity: + - IPMI and host management ports. + - NIC ports connected into 2-node and/or 3-node testbed topologies. + - Main HW configuration: + - Chassis: SuperMicro SYS-740GP-TNRT. + - Motherboard: Super X12DPG-QT6. + - Processors: 2* Intel Platinum 8358 2.6 GHz. + - RAM Memory: 16* 16GB DDR4-3200. + - Disks: 2* 960GB SATA SSD. + - NICs configuration: + - Numa0: (x16, x16, x16 PCIe4.0 lanes) + - PCIe Slot2 4b:00.xx: ConnectX5-2p100GE Mellanox. + - PCIe Slot4 31:00.xx: MCX713106AS-VEAT ConnectX7-2p200GE Nvidia. + - PCIe Slot9 ff:00.xx: MCX713106AS-VEAT ConnectX7-2p200GE Nvidia. + - Numa1: (x16, x16, x16 PCIe4.0 lanes) + - PCIe Slot6 ca:00.xx: empty. + - PCIe Slot8 b1:00.xx: empty. + - PCIe Slot10 ff:00.xx: empty. + +16. **Server-Type-G1**: Purpose - SnowRidge Atom SUT for FD.io performance testing. - Quantity: 2 - Physical connectivity: - IPMI and host management ports. @@ -607,7 +482,7 @@ FD.io CSIT lab contains following server types: - Numa0: (x16, PCIe3.0 lane) - PCIe BuiltIn ec:00.xx: e810-XXVDA4-4p25GE Intel. -23. **Server-Type-H1**: Purpose - SapphireRapids Xeon SUT for FD.io full system performance testing. +17. **Server-Type-H1**: Purpose - SapphireRapids Xeon SUT for FD.io full system performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -628,7 +503,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: ConnectX7-2p200GE Nvidia. - PCIe Slot11 d8:00.xx: ConnectX7-2p200GE Nvidia. -24. **Server-Type-H2**: Purpose - SapphireRapids Xeon TG for FD.io full system performance testing. +18. **Server-Type-H2**: Purpose - SapphireRapids Xeon TG for FD.io full system performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -649,7 +524,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: ConnectX7-2p200GE Nvidia. - PCIe Slot11 d8:00.xx: empty. -25. **Server-Type-H3**: Purpose - SapphireRapids Xeon SUT for FD.io performance testing. +19. **Server-Type-H3**: Purpose - SapphireRapids Xeon SUT for FD.io performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -670,7 +545,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: e810-XXVDA4-4p25GE Intel. - PCIe Slot11 d8:00.xx: empty. -26. **Server-Type-H4**: Purpose - SapphireRapids Xeon TG for FD.io performance testing. +20. **Server-Type-H4**: Purpose - SapphireRapids Xeon TG for FD.io performance testing. - Quantity: 1. - Physical connectivity: - IPMI and host management ports. @@ -691,7 +566,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: empty. - PCIe Slot11 d8:00.xx: empty. -27. **Server-Type-H5**: Purpose - SapphireRapids Xeon SUT for FD.io performance testing. +21. **Server-Type-H5**: Purpose - SapphireRapids Xeon SUT for FD.io performance testing. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -712,7 +587,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: empty. - PCIe Slot11 d8:00.xx: empty. -28. **Server-Type-H6**: Purpose - SapphireRapids Xeon TG for FD.io performance testing. +22. **Server-Type-H6**: Purpose - SapphireRapids Xeon TG for FD.io performance testing. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -733,7 +608,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: e810-2CQDA2-2p100GE Intel. - PCIe Slot11 d8:00.xx: empty. -29. **Server-Type-H7**: Purpose - SapphireRapids SUT for FD.io VPP_Device functional tests. +23. **Server-Type-H7**: Purpose - SapphireRapids SUT for FD.io VPP_Device functional tests. - Quantity: 2. - Physical connectivity: - IPMI and host management ports. @@ -754,7 +629,7 @@ FD.io CSIT lab contains following server types: - PCIe Slot9 af:00.xx: empty. - PCIe Slot11 d8:00.xx: empty. -30. **Server-Type-I1**: Purpose - IcelakeD Xeon SUT for FD.io performance testing. +24. **Server-Type-I1**: Purpose - IcelakeD Xeon SUT for FD.io performance testing. - Quantity: 4 - Physical connectivity: - IPMI and host management ports. @@ -769,6 +644,23 @@ FD.io CSIT lab contains following server types: - Numa0: (x16, PCIe4.0 lane) - PCIe BuiltIn ??:00.xx: e810-XXVDA2-2p25GE Intel. +25. **Server-Type-J1**: Purpose - Grace Server SUT for FD.io performance testing. + - Quantity: 1. + - Physical connectivity: + - IPMI and host management ports. + - NIC ports connected into 2-node and/or 3-node testbed topologies. + - Main HW configuration: + - Chassis: NDA. + - Motherboard: NDA. + - Processors: 1* Arm Neoverse V2. + - RAM Memory: NDA. + - Disks: NDA. + - NICs configuration: + - Numa0: (x16, x16, x16, x16 PCIe5.0 lanes) + - PCIe Slot2 ?: ConnectX5-2p100GE Mellanox. + - PCIe Slot4 ?: MCX713106AS-VEAT ConnectX7-2p200GE Nvidia. + - PCIe Slot9 ?: MCX713106AS-VEAT ConnectX7-2p200GE Nvidia. + ## Testbeds Configuration ### 1-Node-Skylake (1n-skx) @@ -776,36 +668,20 @@ FD.io CSIT lab contains following server types: ``` - SUT [Server-Type-B2]: - testbedname: testbed11. - - hostname: s1-t11-sut1. + - hostname: s50-nomad. - IPMI IP: 10.30.50.47 - Host IP: 10.30.51.50 - portnames: - - s1-t11-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s1-t11-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s1-t11-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s1-t11-sut1-c2/p4 - 10GE-port4 x710-4p10GE. - - s1-t11-sut1-c4/p1 - 10GE-port1 x710-4p10GE. - - s1-t11-sut1-c4/p2 - 10GE-port2 x710-4p10GE. - - s1-t11-sut1-c4/p3 - 10GE-port3 x710-4p10GE. - - s1-t11-sut1-c4/p4 - 10GE-port4 x710-4p10GE. - s1-t11-sut1-c6/p1 - 100GE-port1 e810-2p100GE. - s1-t11-sut1-c6/p2 - 100GE-port2 e810-2p100GE. - s1-t11-sut1-c8/p1 - 100GE-port1 e810-2p100GE. - s1-t11-sut1-c8/p2 - 100GE-port2 e810-2p100GE. - SUT [Server-Type-B2]: - testbedname: testbed12. - - hostname: s2-t12-sut1. + - hostname: s51-nomad. - IPMI IP: 10.30.50.48 - Host IP: 10.30.51.51 - portnames: - - s2-t12-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s2-t12-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s2-t12-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s2-t12-sut1-c2/p4 - 10GE-port4 x710-4p10GE. - - s2-t12-sut1-c4/p1 - 10GE-port1 x710-4p10GE. - - s2-t12-sut1-c4/p2 - 10GE-port2 x710-4p10GE. - - s2-t12-sut1-c4/p3 - 10GE-port3 x710-4p10GE. - - s2-t12-sut1-c4/p4 - 10GE-port4 x710-4p10GE. - s2-t12-sut1-c6/p1 - 100GE-port1 e810-2p100GE. - s2-t12-sut1-c6/p2 - 100GE-port2 e810-2p100GE. - s2-t12-sut1-c8/p1 - 100GE-port1 e810-2p100GE. @@ -856,12 +732,20 @@ FD.io CSIT lab contains following server types: - testbedname: testbed15. - hostname: s30-t15-sut1. - IPMI IP: 10.30.50.30 - - Host IP: 10.30.51.31 + - Host IP: 10.30.51.30 - portnames: - s30-t15-sut1-c1/p1 - 100GE-port1 e810-2CQDA2-2p100GE. - s30-t15-sut1-c1/p2 - 100GE-port2 e810-2CQDA2-2p100GE. - s30-t15-sut1-c2/p1 - 100GE-port1 e810-2CQDA2-2p100GE. - s30-t15-sut1-c2/p2 - 100GE-port1 e810-2CQDA2-2p100GE. + - s30-t15-sut1-c7/p1 - 10GE-port1 x710-4p10GE. + - s30-t15-sut1-c7/p2 - 10GE-port2 x710-4p10GE. + - s30-t15-sut1-c7/p3 - 10GE-port3 x710-4p10GE. + - s30-t15-sut1-c7/p4 - 10GE-port4 x710-4p10GE. + - s30-t15-sut1-c9/p1 - 10GE-port1 x710-4p10GE. + - s30-t15-sut1-c9/p2 - 10GE-port2 x710-4p10GE. + - s30-t15-sut1-c9/p3 - 10GE-port3 x710-4p10GE. + - s30-t15-sut1-c9/p4 - 10GE-port4 x710-4p10GE. - SUT [Server-Type-H7]: - testbedname: testbed16. - hostname: s31-t16-sut1. @@ -872,31 +756,14 @@ FD.io CSIT lab contains following server types: - s31-t16-sut1-c1/p2 - 100GE-port2 e810-2CQDA2-2p100GE. - s31-t16-sut1-c2/p1 - 100GE-port1 e810-2CQDA2-2p100GE. - s31-t16-sut1-c2/p2 - 100GE-port1 e810-2CQDA2-2p100GE. -``` - -### 2-Node-IxiaPS1L47 (2n-ps1) - -``` -- SUT [Server-Type-B8]: - - testbedname: testbed25. - - hostname: s25-t25-sut1. - - IPMI IP: 10.30.50.58 - - Host IP: 10.30.51.61 - - portnames: - - s25-t25-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s25-t25-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s25-t25-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s25-t25-sut1-c2/p4 - 10GE-port4 x710-4p10GE. -- TG [Server-Type-B7]: - - testbedname: testbed25. - - hostname: s26-t25-tg1. - - IPMI IP: 10.30.50.59 - - Host IP: 10.30.51.62 - - portnames: - - s26-t25-tg1-p1 - 10GE-port1. - - s26-t25-tg1-p2 - 10GE-port2. - - s26-t25-tg1-p3 - 10GE-port3. - - s26-t25-tg1-p4 - 10GE-port4. + - s31-t16-sut1-c7/p1 - 10GE-port1 x710-4p10GE. + - s31-t16-sut1-c7/p2 - 10GE-port2 x710-4p10GE. + - s31-t16-sut1-c7/p3 - 10GE-port3 x710-4p10GE. + - s31-t16-sut1-c7/p4 - 10GE-port4 x710-4p10GE. + - s31-t16-sut1-c9/p1 - 10GE-port1 x710-4p10GE. + - s31-t16-sut1-c9/p2 - 10GE-port2 x710-4p10GE. + - s31-t16-sut1-c9/p3 - 10GE-port3 x710-4p10GE. + - s31-t16-sut1-c9/p4 - 10GE-port4 x710-4p10GE. ``` ### 2-Node-Cascadelake (2n-clx) @@ -904,91 +771,7 @@ FD.io CSIT lab contains following server types: {{< figure src="/cdocs/testbed-2n-clx.svg" >}} ``` -- SUT [Server-Type-C2]: - - testbedname: testbed27. - - hostname: s33-t27-sut1. - - IPMI IP: 10.30.55.18 - - Host IP: 10.32.8.18 - - portnames: - - s33-t27-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s33-t27-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s33-t27-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s33-t27-sut1-c2/p4 - 10GE-port4 x710-4p10GE. - - s33-t27-sut1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s33-t27-sut1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s33-t27-sut1-c6/p1 - 100GE-port1 e810-2p100GE. - - s33-t27-sut1-c6/p2 - 100GE-port2 e810-2p100GE. - - s33-t27-sut1-c9/p1 - 100GE-port1 ConnectX5-2p100GE. - - s33-t27-sut1-c9/p2 - 100GE-port2 ConnectX5-2p100GE. -- TG [Server-Type-C3]: - - testbedname: testbed27. - - hostname: s34-t27-tg1. - - IPMI IP: 10.30.55.19 - - Host IP: 10.32.8.19 - - portnames: - - s34-t27-tg1-c2/p1 - 10GE-port1 x710-4p10GE. - - s34-t27-tg1-c2/p2 - 10GE-port2 x710-4p10GE. - - s34-t27-tg1-c2/p3 - 10GE-port3 x710-4p10GE. - - s34-t27-tg1-c2/p4 - 10GE-port4 x710-4p10GE. - - s34-t27-tg1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s34-t27-tg1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s34-t27-tg1-c6/p1 - 100GE-port1 ConnectX5-2p100GE. - - s34-t27-tg1-c6/p2 - 100GE-port2 ConnectX5-2p100GE. - - s38-t27-tg1-c8/p1 - 100GE-port1 ConnectX5-2p100GE. - - s38-t27-tg1-c8/p2 - 100GE-port2 ConnectX5-2p100GE. - - s34-t27-tg1-c9/p1 - 100GE-port1 ConnectX5-2p100GE. - - s34-t27-tg1-c9/p2 - 100GE-port2 ConnectX5-2p100GE. -- SUT [Server-Type-C2]: - - testbedname: testbed28. - - hostname: s35-t28-sut1. - - IPMI IP: 10.30.55.20 - - Host IP: 10.32.8.20 - - portnames: - - s35-t28-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s35-t28-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s35-t28-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s35-t28-sut1-c2/p4 - 10GE-port4 x710-4p10GE. - - s35-t28-sut1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s35-t28-sut1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s35-t28-sut1-c6/p1 - 100GE-port1 e810-2p100GE. - - s35-t28-sut1-c6/p2 - 100GE-port2 e810-2p100GE. - - s35-t28-sut1-c9/p1 - 100GE-port1 ConnectX5-2p100GE. - - s35-t28-sut1-c9/p2 - 100GE-port2 ConnectX5-2p100GE. -- TG [Server-Type-C3]: - - testbedname: testbed28. - - hostname: s36-t28-tg1. - - IPMI IP: 10.30.55.21 - - Host IP: 10.32.8.21 - - portnames: - - s36-t28-tg1-c2/p1 - 10GE-port1 x710-4p10GE. - - s36-t28-tg1-c2/p2 - 10GE-port2 x710-4p10GE. - - s36-t28-tg1-c2/p3 - 10GE-port3 x710-4p10GE. - - s36-t28-tg1-c2/p4 - 10GE-port4 x710-4p10GE. - - s36-t28-tg1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s36-t28-tg1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s36-t28-tg1-c6/p1 - 100GE-port1 ConnectX5-2p100GE. - - s36-t28-tg1-c6/p2 - 100GE-port2 ConnectX5-2p100GE. - - s38-t28-tg1-c8/p1 - 100GE-port1 ConnectX5-2p100GE. - - s38-t28-tg1-c8/p2 - 100GE-port2 ConnectX5-2p100GE. - - s36-t28-tg1-c9/p1 - 100GE-port1 ConnectX5-2p100GE. - - s36-t28-tg1-c9/p2 - 100GE-port2 ConnectX5-2p100GE. -- SUT [Server-Type-C2]: - - testbedname: testbed29. - - hostname: s37-t29-sut1. - - IPMI IP: 10.30.55.22 - - Host IP: 10.32.8.22 - - portnames: - - s37-t29-sut1-c2/p1 - 10GE-port1 x710-4p10GE. - - s37-t29-sut1-c2/p2 - 10GE-port2 x710-4p10GE. - - s37-t29-sut1-c2/p3 - 10GE-port3 x710-4p10GE. - - s37-t29-sut1-c2/p4 - 10GE-port4 x710-4p10GE. - - s37-t29-sut1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s37-t29-sut1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s37-t29-sut1-c6/p1 - 100GE-port1 e810-2p100GE. - - s37-t29-sut1-c6/p2 - 100GE-port2 e810-2p100GE. - - s37-t29-sut1-c9/p1 - 100GE-port1 ConnectX5-2p100GE. - - s37-t29-sut1-c9/p2 - 100GE-port2 ConnectX5-2p100GE. -- TG [Server-Type-C3]: +- TG [Server-Type-C2]: - testbedname: testbed29. - hostname: s38-t29-tg1. - IPMI IP: 10.30.55.23 @@ -1041,39 +824,6 @@ FD.io CSIT lab contains following server types: - s61-t210-tg1-c3/p2 - 25GE-port2 xxv710-DA2-2p25GE. ``` -### 2-Node-ThunderX2 (2x-tx2) - -{{< figure src="/cdocs/testbed-2n-tx2.svg" >}} - -``` -- SUT [Server-Type-E22]: - - testbedname: testbed211. - - hostname: s27-t211-sut1. - - IPMI IP: 10.30.50.69 - - Host IP: 10.30.51.69 - - portnames: - - s27-t211-sut1-c18/p1 - 40GE-port1 xl710-QDA2-2p40GE. - - s27-t211-sut1-c18/p2 - 40GE-port2 xl710-QDA2-2p40GE. -- TG [Server-Type-E31]: - - testbedname: testbed33 and testbed211. - - hostname: s19-t33t211-tg1. - - IPMI IP: 10.30.50.46 - - Host IP: 10.30.51.49 - - portnames: - - s19-t33t211-tg1-c2/p1 - 10GE-port1 x710-4p10GE. - - s19-t33t211-tg1-c2/p2 - 10GE-port2 x710-4p10GE. - - s19-t33t211-tg1-c2/p3 - 10GE-port3 x710-4p10GE. - - s19-t33t211-tg1-c2/p4 - 10GE-port4 x710-4p10GE. - - s19-t33t211-tg1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s19-t33t211-tg1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s19-t33t211-tg1-c8/p1 - 40GE-port1 xl710-QDA2-2p40GE. - - s19-t33t211-tg1-c8/p2 - 40GE-port2 xl710-QDA2-2p40GE. - - s19-t33t211-tg1-c10/p1 - 10GE-port1 x710-4p10GE. - - s19-t33t211-tg1-c10/p2 - 10GE-port2 x710-4p10GE. - - s19-t33t211-tg1-c10/p3 - 10GE-port3 x710-4p10GE. - - s19-t33t211-tg1-c10/p4 - 10GE-port4 x710-4p10GE. -``` - ### 2-Node-Icelake (2n-icx) {{< figure src="/cdocs/testbed-2n-icx.svg" >}} @@ -1181,6 +931,13 @@ FD.io CSIT lab contains following server types: - s86-t214-tg1-c6/p2 - 100GE-port2 e810-2CQDA2-2p100GE. - s86-t214-tg1-c8/p1 - 200GE-port1 ConnectX7-2p200GE. - s86-t214-tg1-c8/p2 - 200GE-port2 ConnectX7-2p200GE. +``` + +### 2-Node-Icelake (2n-oct) + +{{< figure src="/cdocs/testbed-2n-oct.svg" >}} + +``` - SUT [Server-Type-F1]: - testbedname: testbed215. - hostname: s87-t215-sut1. @@ -1217,51 +974,6 @@ FD.io CSIT lab contains following server types: - s88-t215-tg1-c8/p2 - 200GE-port2 ConnectX7-2p200GE. ``` -### 3-Node-Taishan (3n-tsh) - -{{< figure src="/cdocs/testbed-3n-tsh.svg" >}} - -``` -- SUT [Server-Type-E21]: - - testbedname: testbed33. - - hostname: s17-t33-sut1. - - IPMI IP: 10.30.50.36 - - Host IP: 10.30.51.36 - - portnames: - - s17-t33-sut1-c6/p1 - 10GE-port1 x520-2p10GE. - - s17-t33-sut1-c6/p2 - 10GE-port2 x520-2p10GE. - - s17-t33-sut1-c4/p1 - 25GE-port1 cx4-2p25GE. - - s17-t33-sut1-c4/p2 - 25GE-port2 cx4-2p25GE. -- SUT [Server-Type-E21]: - - testbedname: testbed33. - - hostname: s18-t33-sut2. - - IPMI IP: 10.30.50.37 - - Host IP: 10.30.51.37 - - portnames: - - s18-t33-sut2-c6/p1 - 10GE-port1 x520-2p10GE. - - s18-t33-sut2-c6/p2 - 10GE-port2 x520-2p10GE. - - s18-t33-sut2-c4/p1 - 25GE-port1 cx4-2p25GE. - - s18-t33-sut2-c4/p2 - 25GE-port2 cx4-2p25GE. -- TG [Server-Type-E31]: - - testbedname: testbed33 and testbed211. - - hostname: s19-t33t211-tg1. - - IPMI IP: 10.30.50.46 - - Host IP: 10.30.51.49 - - portnames: - - s19-t33t211-tg1-c2/p1 - 10GE-port1 x710-4p10GE. - - s19-t33t211-tg1-c2/p2 - 10GE-port2 x710-4p10GE. - - s19-t33t211-tg1-c2/p3 - 10GE-port3 x710-4p10GE. - - s19-t33t211-tg1-c2/p4 - 10GE-port4 x710-4p10GE. - - s19-t33t211-tg1-c4/p1 - 25GE-port1 xxv710-DA2-2p25GE. - - s19-t33t211-tg1-c4/p2 - 25GE-port2 xxv710-DA2-2p25GE. - - s19-t33t211-tg1-c8/p1 - 40GE-port1 xl710-QDA2-2p40GE. - - s19-t33t211-tg1-c8/p2 - 40GE-port2 xl710-QDA2-2p40GE. - - s19-t33t211-tg1-c10/p1 - 10GE-port1 x710-4p10GE. - - s19-t33t211-tg1-c10/p2 - 10GE-port2 x710-4p10GE. - - s19-t33t211-tg1-c10/p3 - 10GE-port3 x710-4p10GE. - - s19-t33t211-tg1-c10/p4 - 10GE-port4 x710-4p10GE. -``` - ### 3-Node-Altra (3n-alt) {{< figure src="/cdocs/testbed-3n-alt.svg" >}} @@ -1429,7 +1141,7 @@ FD.io CSIT lab contains following server types: - s94-t39-sut2-c1/p2 - 25GE-port2 e810-XXVDA4-4p25GE. - s94-t39-sut2-c1/p3 - 25GE-port3 e810-XXVDA4-4p25GE. - s94-t39-sut2-c1/p4 - 25GE-port4 e810-XXVDA4-4p25GE. -- ServerF4 [Server-Type-F5]: +- ServerC2 [Server-Type-C2]: - testbedname: testbed39. - hostname: s89-t39t310-tg1. - IPMI IP: 10.30.50.89 @@ -1633,39 +1345,37 @@ FD.io CSIT lab contains following server types: - s90-t31t32-tg1-c6/p4 - 25GE-port4 e810-XXVDA4-4p25GE. ``` -## Testbed Wiring - -### 1-Node-Skylake (1n-skx) +### 2-Node-Grace (2n-grc) ``` -- testbed11: - - ring1 10GE-ports x710-4p10GE: - - s1-t11-sut1-c2/p1 to s1-t11-sut1-c4/p1. - - ring2 10GE-ports x710-4p10GE: - - s1-t11-sut1-c2/p2 to s1-t11-sut1-c4/p2. - - ring3 10GE-ports x710-4p10GE: - - s1-t11-sut1-c2/p3 to s1-t11-sut1-c4/p3. - - ring4 10GE-ports x710-4p10GE: - - s1-t11-sut1-c2/p4 to s1-t11-sut1-c4/p4. - - ring5 100GE-ports e810-2p100GE: - - s1-t11-sut1-c5/p1 to s1-t11-sut1-c6/p1. - - ring6 100GE-ports e810-2p100GE: - - s1-t11-sut1-c5/p2 to s1-t11-sut1-c6/p2. -- testbed12: - - ring1 10GE-ports x710-4p10GE: - - s2-t12-sut1-c2/p1 to s2-t12-sut1-c4/p1. - - ring2 10GE-ports x710-4p10GE: - - s2-t12-sut1-c2/p2 to s2-t12-sut1-c4/p2. - - ring3 10GE-ports x710-4p10GE: - - s2-t12-sut1-c2/p3 to s2-t12-sut1-c4/p3. - - ring4 10GE-ports x710-4p10GE: - - s2-t12-sut1-c2/p4 to s2-t12-sut1-c4/p4. - - ring5 100GE-ports e810-2p100GE: - - s2-t12-sut1-c5/p1 to s2-t12-sut1-c6/p1. - - ring6 100GE-ports e810-2p100GE: - - s2-t12-sut1-c5/p2 to s2-t12-sut1-c6/p2. +- SUT [Server-Type-J1]: + - testbedname: testbed27. + - hostname: s36-t27-sut1. + - IPMI IP: 10.30.50.36 + - Host IP: 10.30.51.36 + - portnames: + - s36-t27-sut1-c2/p1 - 100GE-port1 ConnectX5-2p100GE. + - s36-t27-sut1-c2/p2 - 100GE-port2 ConnectX5-2p100GE. + - s36-t27-sut1-c4/p1 - 200GE-port1 ConnectX7-2p200GE. + - s36-t27-sut1-c4/p2 - 200GE-port2 ConnectX7-2p200GE. + - s36-t27-sut1-c9/p1 - 200GE-port1 ConnectX7-2p200GE. + - s36-t27-sut1-c9/p2 - 200GE-port2 ConnectX7-2p200GE. +- TG [Server-Type-F6]: + - testbedname: testbed27. + - hostname: s37-t27-tg1. + - IPMI IP: 10.30.50.37 + - Host IP: 10.30.51.37 + - portnames: + - s37-t27-tg1-c2/p1 - 100GE-port1 ConnectX5-2p100GE. + - s37-t27-tg1-c2/p2 - 100GE-port2 ConnectX5-2p100GE. + - s37-t27-tg1-c4/p1 - 200GE-port1 ConnectX7-2p200GE. + - s37-t27-tg1-c4/p2 - 200GE-port2 ConnectX7-2p200GE. + - s37-t27-tg1-c9/p1 - 200GE-port1 ConnectX7-2p200GE. + - s37-t27-tg1-c9/p2 - 200GE-port2 ConnectX7-2p200GE. ``` +## Testbed Wiring + ### 1-Node-Altra (1n-alt) ``` @@ -1702,84 +1412,27 @@ FD.io CSIT lab contains following server types: - s30-t15-sut1-c1/p1 to s30-t15-sut1-c2/p1. - ring2 100GE-ports e810-2p100GE: - s30-t15-sut1-c1/p2 to s30-t15-sut1-c2/p2. + - ring3 10GE-ports x710-4p10GE: + - s30-t15-sut1-c7/p1 to s30-t15-sut1-c9/p1. + - ring4 10GE-ports x710-4p10GE: + - s30-t15-sut1-c7/p2 to s30-t15-sut1-c9/p2. + - ring5 10GE-ports x710-4p10GE: + - s30-t15-sut1-c7/p3 to s30-t15-sut1-c9/p3. + - ring6 10GE-ports x710-4p10GE: + - s30-t15-sut1-c7/p4 to s30-t15-sut1-c9/p4. - testbed16: - ring1 100GE-ports e810-2p100GE: - s31-t16-sut1-c1/p1 to s31-t16-sut1-c2/p1. - ring2 100GE-ports e810-2p100GE: - s31-t16-sut1-c1/p2 to s31-t16-sut1-c2/p2. -``` - -### 2-Node-IxiaPS1L47 (2n-ps1) - -``` -- testbed25: - - link1 10GE-port x710-4p10GE on SUT: - - t25-tg1-p1 to t25-sut1-c2/p1. - - link2 10GE-port x710-4p10GE on SUT: - - t25-tg1-p2 to t25-sut1-c2/p2. - - link3 10GE-port x710-4p10GE on SUT: - - t25-tg1-p3 to t25-sut1-c2/p3. - - link4 10GE-port x710-4p10GE on SUT: - - t25-tg1-p4 to t25-sut1-c2/p4. -``` - -### 2-Node-Cascadelake (2n-clx) - -``` -- testbed27: - - ring1 10GE-ports x710-4p10GE on SUT: - - s34-t27-tg1-c2/p1 to s33-t27-sut1-c2/p1. - - s33-t27-sut1-c2/p2 to s34-t27-tg1-c2/p2. - - ring2 10GE-ports x710-4p10GE on SUT: - - s34-t27-tg1-c2/p3 to s33-t27-sut1-c2/p3. - - s33-t27-sut1-c2/p4 to s34-t27-tg1-c2/p4. - - ring3 25GE-ports xxv710-DA2-2p25GE on SUT - - s34-t27-tg1-c4/p1 to s33-t27-sut1-c4/p1. - - s33-t27-sut1-c4/p2 to s34-t27-tg1-c4/p2. - - ring4 100GE-ports ConnectX5-2p100GE on SUT: - - s34-t27-tg1-c9/p1 to s33-t27-sut1-c9/p1. - - s33-t27-sut1-c9/p2 to s34-t27-tg1-c9/p2. - - ring5 100GE-ports e810-2p100GE on SUT 100GE-ports ConnectX5-2p100GE on TG: - - s34-t27-tg1-c6/p1 to s33-t27-sut1-c6/p1. - - s33-t27-sut1-c6/p2 to s34-t27-tg1-c6/p2. - - ring6 100GE-ports e810-2p100GE on TG: - - s34-t27-tg1-c8/p1 to s34-t27-tg1-c8/p2. - - s34-t27-tg1-c8/p2 to s34-t27-tg1-c8/p1. -- testbed28: - - ring1 10GE-ports x710-4p10GE on SUT: - - s36-t28-tg1-c2/p1 to s35-t28-sut1-c2/p1. - - s35-t28-sut1-c2/p2 to s36-t28-tg1-c2/p2. - - ring2 10GE-ports x710-4p10GE on SUT: - - s36-t28-tg1-c2/p3 to s35-t28-sut1-c2/p3. - - s35-t28-sut1-c2/p4 to s36-t28-tg1-c2/p4. - - ring3 25GE-ports xxv710-DA2-2p25GE on SUT - - s36-t28-tg1-c4/p1 to s35-t28-sut1-c4/p1. - - s35-t28-sut1-c4/p2 to s36-t28-tg1-c4/p2. - - ring4 100GE-ports ConnectX5-2p100GE on SUT: - - s36-t28-tg1-c9/p1 to s35-t28-sut1-c9/p1. - - s35-t28-sut1-c9/p2 to s36-t28-tg1-c9/p2. - - ring5 100GE-ports e810-2p100GE on SUT 100GE-ports ConnectX5-2p100GE on TG: - - s36-t28-tg1-c6/p1 to s35-t28-sut1-c6/p1. - - s35-t28-sut1-c6/p2 to s36-t28-tg1-c6/p2. - - ring6 100GE-ports e810-2p100GE on TG: - - s36-t28-tg1-c8/p1 to s36-t28-tg1-c8/p2. - - s36-t28-tg1-c8/p2 to s36-t28-tg1-c8/p1. -- testbed29: - - ring1 10GE-ports x710-4p10GE on SUT: - - s38-t29-tg1-c2/p1 to s37-t29-sut1-c2/p1. - - s37-t29-sut1-c2/p2 to s38-t29-tg1-c2/p2. - - ring2 10GE-ports x710-4p10GE on SUT: - - s38-t29-tg1-c2/p3 to s37-t29-sut1-c2/p3. - - s37-t29-sut1-c2/p4 to s38-t29-tg1-c2/p4. - - ring3 25GE-ports xxv710-DA2-2p25GE on SUT - - s38-t29-tg1-c4/p1 to s37-t29-sut1-c4/p1. - - s37-t29-sut1-c4/p2 to s38-t29-tg1-c4/p2. - - ring4 100GE-ports ConnectX5-2p100GE on SUT: - - s38-t29-tg1-c9/p1 to s37-t29-sut1-c9/p1. - - s37-t29-sut1-c9/p2 to s38-t29-tg1-c9/p2. - - ring5 100GE-ports e810-2p100GE on SUT 100GE-ports ConnectX5-2p100GE on TG: - - s38-t29-tg1-c6/p1 to s37-t29-sut1-c6/p1. - - s37-t29-sut1-c6/p2 to s38-t29-tg1-c6/p2. + - ring3 10GE-ports x710-4p10GE: + - s31-t16-sut1-c9/p1 to s31-t16-sut1-c9/p1. + - ring4 10GE-ports x710-4p10GE: + - s31-t16-sut1-c9/p2 to s31-t16-sut1-c9/p2. + - ring5 10GE-ports x710-4p10GE: + - s31-t16-sut1-c9/p3 to s31-t16-sut1-c9/p3. + - ring6 10GE-ports x710-4p10GE: + - s31-t16-sut1-c9/p4 to s31-t16-sut1-c9/p4. ``` ### 2-Node-Zen2 (2n-zn2) @@ -1800,15 +1453,6 @@ FD.io CSIT lab contains following server types: - s60-t210-sut1-c3/p2 to s61-t210-tg1-c1/p2. ``` -### 2-Node-ThunderX2 (2n-tx2) - -``` -- testbed211: - - ring1 10GE-ports x520-2p10GE on SUTs: - - s27-t211-sut1-c18/p1 - s19-t33t211-tg1-c8/p1. - - s27-t211-sut1-c18/p2 - s19-t33t211-tg1-c8/p2. -``` - ### 2-Node-Icelake (2n-icx) ``` @@ -1866,6 +1510,11 @@ FD.io CSIT lab contains following server types: - ring5 200GE-ports ConnectX7-2p200GE: - s86-t214-tg1-c8/p1 to s85-t214-sut1-c8/p1. - s85-t214-sut1-c8/p2 to s86-t214-tg1-c8/p2. +``` + +### 2-Node-Icelake (2n-oct) + +``` - testbed215: - ring1 25GE-ports xxv710-DA2-2p25GE: - s88-t215-tg1-c2/p1 to s87-t215-sut1-c2/p1. @@ -1886,26 +1535,6 @@ FD.io CSIT lab contains following server types: - s87-t215-sut1-c8/p2 to s88-t215-tg1-c8/p2. ``` -### 3-Node-Rangeley (3n-rng) - -``` -To be completed. -``` - -### 3-Node-Taishan (3n-tsh) - -``` -- testbed33: - - ring1 10GE-ports x520-2p10GE on SUTs: - - s19-t33t211-tg1-c2/p2 - s17-t33-sut1-c6/p2. - - s17-t33-sut1-c6/p1 - s18-t33-sut2-c6/p2. - - s18-t33-sut2-c6/p1 - s19-t33t211-tg1-c2/p1. - - ring2 25GE-ports cx4-2p25GE on SUTs: - - s19-t33t211-tg1-c4/p2 - s17-t33-sut1-c4/p2. - - s17-t33-sut1-c4/p1 - s18-t33-sut2-c4/p2. - - s18-t33-sut2-c4/p1 - s19-t33t211-tg1-c4/p1. -``` - ### 3-Node-Altra (3n-alt) ``` @@ -2050,4 +1679,19 @@ To be completed. - s90-t31t32-tg1-c6/p1 to s34-t32-sut1-c1/p1. - s34-t32-sut1-c1/p2 to s35-t32-sut2-c1/p2. - s35-t32-sut2-c1/p1 to s90-t31t32-tg1-c6/p2. +``` + +### 2-Node-GraceServer (2n-grc) + +``` +- testbed27: + - ring1 100GE-ports ConnectX5-2p100GE: + - s37-t27-tg1-c2/p1 to s36-t27-sut1-c1/p1. + - s36-t27-sut1-c1/p2 to s37-t27-tg1-c2/p2. + - ring2 200GE-ports ConnectX7-2p200GE: + - s37-t27-tg1-c2/p1 to s36-t27-sut1-c1/p1. + - s36-t27-sut1-c1/p2 to s37-t27-tg1-c2/p2. + - ring3 200GE-ports ConnectX7-2p200GE: + - s37-t27-tg1-c2/p1 to s36-t27-sut1-c1/p1. + - s36-t27-sut1-c1/p2 to s37-t27-tg1-c2/p2. ```
\ No newline at end of file diff --git a/docs/content/infrastructure/fdio_dc_vexxhost_inventory.md b/docs/content/infrastructure/fdio_dc_vexxhost_inventory.md index b4741cf5d2..bd12845fe7 100644 --- a/docs/content/infrastructure/fdio_dc_vexxhost_inventory.md +++ b/docs/content/infrastructure/fdio_dc_vexxhost_inventory.md @@ -19,14 +19,6 @@ Captured inventory data: - **rackid**: new location rack id. - **rackunit**: new location rack unit id. -## Missing Equipment Inventory - -1. Ixia PerfectStorm One Appliance - - [**Specification**]({{< ref "fdio_dc_testbed_specifications#2-node-ixiaps1l47-ixia-psone-l47-2n-ps1" >}}) - - [**Wiring**]({{< ref "fdio_dc_testbed_specifications#2-node-ixiaps1l47-2n-ps1" >}}) - - **mgmt-ip4**: 10.30.51.62 s26-t25-tg1 - - **ipmi-ip4**: 10.30.50.59 s26-t25-tg1 - ## YUL1 Inventory ### Rack YUL1-8 (3016.8) @@ -43,8 +35,8 @@ Captured inventory data: s84-t213-tg1 | 2n-icx | SYS-740GP-TNRT | C7470KL03P50187 | 10.30.51.84 | 10.30.50.84 | 3016.8 | u18-u21 s85-t214-sut1 | 2n-icx | SYS-740GP-TNRT | C7470KK33P50219 | 10.30.51.85 | 10.30.50.85 | 3016.8 | u14-u17 s86-t214-tg1 | 2n-icx | SYS-740GP-TNRT | C7470KL07P50312 | 10.30.51.86 | 10.30.50.86 | 3016.8 | u10-u13 - s87-t215-sut1 | 2n-icx | SYS-740GP-TNRT | C7470KL03P50171 | 10.30.51.87 | 10.30.50.87 | 3016.8 | u6-u9 - s88-t215-tg1 | 2n-icx | SYS-740GP-TNRT | C7470KL07P50301 | 10.30.51.88 | 10.30.50.88 | 3016.8 | u2-u5 + s87-t215-sut1 | 2n-oct | SYS-740GP-TNRT | C7470KL03P50171 | 10.30.51.87 | 10.30.50.87 | 3016.8 | u6-u9 + s88-t215-tg1 | 2n-oct | SYS-740GP-TNRT | C7470KL07P50301 | 10.30.51.88 | 10.30.50.88 | 3016.8 | u2-u5 ### Rack YUL1-9 (3016.9) @@ -57,21 +49,19 @@ Captured inventory data: s55-t22-tg1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.55 | 10.30.50.55 | 3016.9 | u30-u33 s56-t23-sut1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.56 | 10.30.50.56 | 3016.9 | u26-u29 s57-t23-tg1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.57 | 10.30.50.57 | 3016.9 | u22-u25 - s25-t25-sut1 | 2n-p1 | SYS-7049GP-TRT | C7470KH06A20022 | 10.30.51.61 | 10.30.50.58 | 3016.9 | u18-u21 - s19-t33t211-tg1 | 3n-tsh/2n-tx2 | SYS-7049GP-TRT | C7470KH06A20056 | 10.30.51.49 | 10.30.50.46 | 3016.9 | u14-u17 - s27-t211-sut1 | 2n-tx2 | ThunderX2-9975 | K61186073100003 | 10.30.51.69 | 10.30.50.69 | 3016.9 | u13 - s18-t33-sut2 | 3n-tsh | HUAWEI-TAISHAN-2280 | N/A | 10.30.51.37 | 10.30.50.37 | 3016.9 | u11-u12 - s17-t33-sut1 | 3n-tsh | HUAWEI-TAISHAN-2280 | N/A | 10.30.51.36 | 10.30.50.36 | 3016.9 | u9-u10 + s58-t24-sut1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.58 | 10.30.50.58 | 3016.9 | u18-u21 + s59-t24-tg1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.59 | 10.30.50.59 | 3016.9 | u14-u17 + s78-t38-sut1 | 3n-icx | SYS-740GP-TNRT | C7470KL03P50450 | 10.30.51.78 | 10.30.50.78 | 3016.9 | u10-u13 + s79-t38-sut2 | 3n-icx | SYS-740GP-TNRT | C7470KL07P50297 | 10.30.51.79 | 10.30.50.79 | 3016.9 | u6-u9 + s80-t38-tg1 | 3n-icx | SYS-740GP-TNRT | C7470KL03P50454 | 10.30.51.80 | 10.30.50.80 | 3016.9 | u2-u5 ### Rack YUL1-10 (3016.10) **name** | **role** | **model** | **s/n** | **mgmt-ip4** | **ipmi-ip4** | **rackid** | **rackunit** -----------------|---------------|---------------------|-----------------|--------------|--------------|------------|-------------- yul1-10-lb4m | uplink | ? | ? | ? | ? | 3016.10 | u47 - s2-t12-sut1 | 1n-skx | SYS-7049GP-TRT | C7470KH06A20119 | 10.30.51.51 | 10.30.50.48 | 3016.10 | u42-u45 - s1-t11-sut1 | 1n-skx | SYS-7049GP-TRT | C7470KH06A20154 | 10.30.51.50 | 10.30.50.47 | 3016.10 | u38-u41 - s58-t24-sut1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.58 | 10.30.50.58 | 3016.10 | u34-u37 - s59-t24-tg1 | 2n-spr | SYS-741GE-TNRT | ??? | 10.30.51.59 | 10.30.50.59 | 3016.10 | u30-u33 + s51-nomad | nomad-client | SYS-7049GP-TRT | C7470KH06A20119 | 10.30.51.51 | 10.30.50.48 | 3016.10 | u42-u45 + s50-nomad | nomad-client | SYS-7049GP-TRT | C7470KH06A20154 | 10.30.51.50 | 10.30.50.47 | 3016.10 | u38-u41 s32-t31-sut1 | 3n-icxd | SYS-110D-20C-FRDN8TP| C515MKK41A30950 | 10.30.51.32 | 10.30.50.32 | 3016.10 | u21 s33-t31-sut2 | 3n-icxd | SYS-110D-20C-FRDN8TP| C515MKK41A30967 | 10.30.51.33 | 10.30.50.33 | 3016.10 | u20 s34-t32-sut1 | 3n-icxd | SYS-110D-20C-FRDN8TP| C515MKK41A30959 | 10.30.51.34 | 10.30.50.34 | 3016.10 | u19 @@ -79,8 +69,7 @@ Captured inventory data: s90-t31t32-tg1 | 3n-icxd | SYS-740GP-TNRT | C7470KL03P50184 | 10.30.51.90 | 10.30.50.90 | 3016.10 | u14-u17 s93-t39-sut1 | 3n-snr | ? | ? | 10.30.51.93 | 10.30.50.93 | 3016.10 | u10-u13 s94-t39-sut2 | 3n-snr | ? | ? | 10.30.51.94 | 10.30.50.94 | 3016.10 | u6-u9 - s89-t39t310-tg1 | 3n-snr | ? | ? | 10.30.51.89 | 10.30.50.89 | 3016.10 | u2-u5 - + s89-t39t310-tg1 | 3n-snr | SYS-7049GP-TRT | C7470KH37A30506 | 10.30.51.89 | 10.30.50.89 | 3016.10 | u2-u5 ### Rack YUL1-11 (3016.11) @@ -92,9 +81,6 @@ Captured inventory data: fdio-marvell-dev | dev | ThunderX-88XX | N/A | 10.30.51.38 | 10.30.50.38 | 3016.11 | u45 s21-nomad | nomad-client | SYS-741GE-TNRT | C7490FL47A50150 | 10.30.51.21 | 10.30.50.21 | 3016.11 | u39-u42 s22-nomad | nomad-client | SYS-741GE-TNRT | C7490FL47A50155 | 10.30.51.22 | 10.30.50.22 | 3016.11 | u35-u38 - s78-t38-sut1 | 3n-icx | SYS-740GP-TNRT | C7470KL03P50450 | 10.30.51.78 | 10.30.50.78 | 3016.11 | u31-u34 - s79-t38-sut2 | 3n-icx | SYS-740GP-TNRT | C7470KL07P50297 | 10.30.51.79 | 10.30.50.79 | 3016.11 | u27-u30 - s80-t38-tg1 | 3n-icx | SYS-740GP-TNRT | C7470KL03P50454 | 10.30.51.80 | 10.30.50.80 | 3016.11 | u23-u26 s30-t15-sut1 | nomad-client | SYS-741GE-TNRT | C7490FL47A50154 | 10.30.51.30 | 10.30.50.30 | 3016.11 | u19-u22 s31-t16-sut1 | nomad-client | SYS-741GE-TNRT | C7490FL47A50149 | 10.30.51.31 | 10.30.50.31 | 3016.11 | u15-u18 s70-t13-sut1 | 1n-alt | E252-P30-00 | GMG252012A0098 | 10.30.51.70 | 10.30.50.70 | 3016.11 | u13-u14 @@ -112,15 +98,11 @@ Captured inventory data: s27-nomad | nomad-client | SYS-7049GP-TRT | C7470KH06A20055 | 10.30.51.27 | 10.30.50.27 | 3016.12 | u37-u40 s91-nomad | nomad-client | R152-P30-00 | GLG4P9912A0016 | 10.30.51.91 | 10.30.50.91 | 3016.12 | u36 s92-nomad | nomad-client | R152-P30-00 | GLG4P9912A0004 | 10.30.51.92 | 10.30.50.92 | 3016.12 | u35 - s23-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0256 | 10.30.51.23 | 10.30.51.23 | 3016.12 | u34 - s24-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0241 | 10.30.51.24 | 10.30.51.24 | 3016.12 | u33 - s25-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0540 | 10.30.51.25 | 10.30.51.25 | 3016.12 | u32 + s23-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0256 | 10.30.51.23 | 10.30.50.23 | 3016.12 | u34 + s24-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0241 | 10.30.51.24 | 10.30.50.24 | 3016.12 | u33 + s25-nomad | nomad-server | SYS-1029P-WTRT | C1160LI12NM0540 | 10.30.51.25 | 10.30.50.25 | 3016.12 | u32 s61-t210-tg1 | 2n-zn2 | AS-1014S-WTRT | C8150LI50NS2689 | 10.32.8.25 | 10.30.55.25 | 3016.12 | u31 s60-t210-sut1 | 2n-zn2 | AS-1114S-WTRT | N/A | 10.32.8.24 | 10.30.55.24 | 3016.12 | u30 - s26-nomad | nomad-server | SYS-7049GP-TRT | C7470KH37A30505 | 10.30.51.26 | 10.30.51.26 | 3016.12 | u26-u29 - s33-t27-sut1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30567 | 10.32.8.18 | 10.30.55.18 | 3016.12 | u22-u25 - s34-t27-tg1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30565 | 10.32.8.19 | 10.30.55.19 | 3016.12 | u18-u21 - s35-t28-sut1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30509 | 10.32.8.20 | 10.30.55.20 | 3016.12 | u14-u17 - s36-t28-tg1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30511 | 10.32.8.21 | 10.30.55.21 | 3016.12 | u10-u13 - s37-t29-sut1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30566 | 10.32.8.22 | 10.30.55.22 | 3016.12 | u6-u9 - s38-t29-tg1 | 2n-clx | SYS-7049GP-TRT | C7470KH37A30506 | 10.32.8.23 | 10.30.55.23 | 3016.12 | u2-u5
\ No newline at end of file + s26-nomad | nomad-server | SYS-7049GP-TRT | C7470KH37A30505 | 10.30.51.26 | 10.30.50.26 | 3016.12 | u26-u29 + s36-t27-sut1 | 2n-grc | -- | -- | 10.30.51.36 | 10.30.50.36 | 3016.12 | u6 + s37-t27-tg1 | 2n-grc | ? | ? | 10.30.51.37 | 10.30.50.37 | 3016.12 | u2-u5
\ No newline at end of file diff --git a/docs/content/infrastructure/testbed_configuration/gigabyte_tx2_hw_bios_cfg.md b/docs/content/infrastructure/testbed_configuration/gigabyte_tx2_hw_bios_cfg.md deleted file mode 100644 index 5020cb70f9..0000000000 --- a/docs/content/infrastructure/testbed_configuration/gigabyte_tx2_hw_bios_cfg.md +++ /dev/null @@ -1,406 +0,0 @@ ---- -bookToc: true -title: "GigaByte ThunderX2" ---- - -# GigaByte ThunderX2 - -## Linux lscpu - -``` -Architecture: aarch64 - CPU op-mode(s): 64-bit - Byte Order: Little Endian -CPU(s): 56 - On-line CPU(s) list: 0-55 -Vendor ID: Cavium - Model name: ThunderX2 99xx - Model: 1 - Thread(s) per core: 1 - Core(s) per socket: 28 - Socket(s): 2 - Stepping: 0x1 - Frequency boost: disabled - CPU max MHz: 2000.0000 - CPU min MHz: 1000.0000 - BogoMIPS: 400.00 - Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm -Caches (sum of all): - L1d: 1.8 MiB (56 instances) - L1i: 1.8 MiB (56 instances) - L2: 14 MiB (56 instances) - L3: 64 MiB (2 instances) -NUMA: - NUMA node(s): 2 - NUMA node0 CPU(s): 0-27 - NUMA node1 CPU(s): 28-55 -Vulnerabilities: - Itlb multihit: Not affected - L1tf: Not affected - Mds: Not affected - Meltdown: Not affected - Mmio stale data: Not affected - Retbleed: Not affected - Spec store bypass: Vulnerable - Spectre v1: Mitigation; __user pointer sanitization - Spectre v2: Vulnerable - Srbds: Not affected - Tsx async abort: Not affected -``` - -## Linux dmidecode - -``` -# dmidecode 3.3 -Getting SMBIOS data from sysfs. -SMBIOS 3.1.1 present. -Table at 0xFE340000. - -Handle 0x0000, DMI type 0, 26 bytes -BIOS Information - Vendor: GIGABYTE - Version: F28 - Release Date: 12/27/2019 - Address: 0xF0000 - Runtime Size: 64 kB - ROM Size: 32 MB - Characteristics: - PCI is supported - BIOS is upgradeable - BIOS shadowing is allowed - Boot from CD is supported - Selectable boot is supported - BIOS ROM is socketed - ACPI is supported - BIOS boot specification is supported - Targeted content distribution is supported - UEFI is supported - BIOS Revision: 7.3 - -Handle 0x0001, DMI type 1, 27 bytes -System Information - Manufacturer: GIGABYTE - Product Name: R181-T90-00 - Version: 0100 - Serial Number: GIG7P9512A0022 - UUID: 00000000-0000-0040-8000-e0d55eae7026 - Wake-up Type: Power Switch - SKU Number: SABER SKU - Family: Server - -Handle 0x0002, DMI type 2, 15 bytes -Base Board Information - Manufacturer: GIGABYTE - Product Name: MT91-FS1-00 - Version: 01000100 - Serial Number: IH6P8800035 - Asset Tag: 01234567890123456789AB - Features: - Board is a hosting board - Board is replaceable - Location In Chassis: Default string - Chassis Handle: 0x0003 - Type: Motherboard - Contained Object Handles: 0 - -Handle 0x0003, DMI type 3, 22 bytes -Chassis Information - Manufacturer: GIGABYTE - Type: Rack Mount Chassis - Lock: Not Present - Version: 1.0 - Serial Number: K61186073100003 - Asset Tag: 01234567890123456789AB - Boot-up State: Safe - Power Supply State: Safe - Thermal State: Safe - Security Status: None - OEM Information: 0x00000000 - Height: Unspecified - Number Of Power Cords: 1 - Contained Elements: 0 - SKU Number: Default string - -Handle 0x0004, DMI type 10, 6 bytes -On Board Device Information - Type: Unknown - Status: Enabled - Description: Device 1 - -Handle 0x0005, DMI type 12, 5 bytes -System Configuration Options - Option 1: Default string - -Handle 0x0006, DMI type 13, 22 bytes -BIOS Language Information - Language Description Format: Long - Installable Languages: 1 - en|US|iso8859-1 - Currently Installed Language: en|US|iso8859-1 - -Handle 0x0007, DMI type 31, 28 bytes -Boot Integrity Services Entry Point - Checksum: Invalid - 16-bit Entry Point Address: FFFF:FFFF - 32-bit Entry Point Address: 0xFFFFFFFF - -Handle 0x0008, DMI type 32, 11 bytes -System Boot Information - Status: No errors detected - -Handle 0x0009, DMI type 39, 22 bytes -System Power Supply - Power Unit Group: 1 - Location: CHINA - Name: FSP1200-20ERM - Manufacturer: FSP GROUP - Serial Number: WS8011100823 - Asset Tag: Default string - Model Part Number: FSP1200-20ERM - Revision: 10 - Max Power Capacity: 2648 W - Status: Present, OK - Type: Switching - Input Voltage Range Switching: Auto-switch - Plugged: Yes - Hot Replaceable: No - -Handle 0x0010, DMI type 39, 22 bytes -System Power Supply - Power Unit Group: 1 - Location: CHINA - Name: FSP1200-20ERM - Manufacturer: FSP GROUP - Serial Number: WS8011100830 - Asset Tag: Default string - Model Part Number: FSP1200-20ERM - Revision: 10 - Max Power Capacity: 2648 W - Status: Present, OK - Type: Switching - Input Voltage Range Switching: Auto-switch - Plugged: Yes - Hot Replaceable: No - -Handle 0x0011, DMI type 41, 11 bytes -Onboard Device - Reference Designation: Device 1 - Type: Unknown - Status: Enabled - Type Instance: 1 - Bus Address: 0000:00:00.0 - -Handle 0x0012, DMI type 41, 11 bytes -Onboard Device - Reference Designation: Device 2 - Type: Unknown - Status: Enabled - Type Instance: 1 - Bus Address: 0000:00:00.0 - -Handle 0x0013, DMI type 41, 11 bytes -Onboard Device - Reference Designation: Device 3 - Type: Unknown - Status: Enabled - Type Instance: 1 - Bus Address: 0000:00:00.0 - -Handle 0x0014, DMI type 41, 11 bytes -Onboard Device - Reference Designation: Device 4 - Type: Unknown - Status: Enabled - Type Instance: 1 - Bus Address: 0000:00:00.0 - -Handle 0x0015, DMI type 41, 11 bytes -Onboard Device - Reference Designation: Device 5 - Type: Unknown - Status: Enabled - Type Instance: 1 - Bus Address: 0000:00:00.0 - -Handle 0x0016, DMI type 38, 18 bytes -IPMI Device Information - Interface Type: SSIF (SMBus System Interface) - Specification Version: 2.0 - I2C Slave Address: 0x10 - NV Storage Device: Not Present - Base Address: 0x10 (SMBus) - -Handle 0x0017, DMI type 42, 12 bytes -Management Controller Host Interface - Interface Type: OEM - Vendor ID: 0xFF0102FF - -Handle 0x0029, DMI type 11, 5 bytes -OEM Strings - String 1: HWID=E38C - String 2: cavium.com - String 3: Saber - -Handle 0x002A, DMI type 13, 22 bytes -BIOS Language Information - Language Description Format: Abbreviated - Installable Languages: 1 - enUS - Currently Installed Language: enUS - -Handle 0x002B, DMI type 4, 48 bytes -Processor Information - Socket Designation: Socket 0 - Type: Central Processor - Family: ARM - Manufacturer: Cavium Inc. - ID: F1 0A 1F 43 00 00 00 00 - Signature: Implementor 0x43, Variant 0x1, Architecture 15, Part 0x0af, Revision 1 - Version: Cavium ThunderX2(R) CPU CN9975 v2.1 @ 2.0GHz - Voltage: 0.8 V - External Clock: 33 MHz - Max Speed: 2500 MHz - Current Speed: 2000 MHz - Status: Populated, Enabled - Upgrade: Other - L1 Cache Handle: 0x002C - L2 Cache Handle: 0x002E - L3 Cache Handle: 0x002F - Serial Number: 000081D4-4003326A - Asset Tag: Not Specified - Part Number: CN9975-2000BG4077-Y21-G - Core Count: 28 - Core Enabled: 28 - Thread Count: 28 - Characteristics: - 64-bit capable - Multi-Core - Hardware Thread - Execute Protection - Enhanced Virtualization - Power/Performance Control -``` - -## Linux dmidecode memory - -``` -Handle 0x003E, DMI type 16, 23 bytes -Physical Memory Array - Location: System Board Or Motherboard - Use: System Memory - Error Correction Type: Multi-bit ECC - Maximum Capacity: 2 TB - Error Information Handle: Not Provided - Number Of Devices: 12 - -Handle 0x003F, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x003E - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 32 GB - Form Factor: DIMM - Set: None - Locator: DIMM_P0_A0 - Bank Locator: N0 - Type: DDR4 - Type Detail: Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Micron Technology - Serial Number: 469570327 - Asset Tag: Not Specified - Part Number: 36ASF4G72PZ-2G3B1 - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - -Handle 0x0040, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x003E - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 32 GB - Form Factor: DIMM - Set: None - Locator: DIMM_P0_B0 - Bank Locator: N0 - Type: DDR4 - Type Detail: Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Micron Technology - Serial Number: 469570172 - Asset Tag: Not Specified - Part Number: 36ASF4G72PZ-2G3B1 - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - -Handle 0x0050, DMI type 16, 23 bytes -Physical Memory Array - Location: System Board Or Motherboard - Use: System Memory - Error Correction Type: Multi-bit ECC - Maximum Capacity: 2 TB - Error Information Handle: Not Provided - Number Of Devices: 12 - -Handle 0x0051, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0050 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 32 GB - Form Factor: DIMM - Set: None - Locator: DIMM_P1_I0 - Bank Locator: N1 - Type: DDR4 - Type Detail: Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Micron Technology - Serial Number: 469567519 - Asset Tag: Not Specified - Part Number: 36ASF4G72PZ-2G3B1 - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - -Handle 0x0052, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0050 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 32 GB - Form Factor: DIMM - Set: None - Locator: DIMM_P1_J0 - Bank Locator: N1 - Type: DDR4 - Type Detail: Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Micron Technology - Serial Number: 469567696 - Asset Tag: Not Specified - Part Number: 36ASF4G72PZ-2G3B1 - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V -``` - -## Linux cmdline - -``` -BOOT_IMAGE=/boot/vmlinuz-5.4.0-65-generic root=UUID=7d1d0e77-4df0-43df-9619-a99db29ffb83 ro audit=0 intel_iommu=on isolcpus=1-27,29-55 nmi_watchdog=0 nohz_full=1-27,29-55 nosoftlockup processor.max_cstate=1 rcu_nocbs=1-27,29-55 console=ttyAMA0,115200n8 quiet -``` diff --git a/docs/content/infrastructure/testbed_configuration/huawei_tsh_hw_bios_cfg.md b/docs/content/infrastructure/testbed_configuration/huawei_tsh_hw_bios_cfg.md deleted file mode 100644 index 6803fd615b..0000000000 --- a/docs/content/infrastructure/testbed_configuration/huawei_tsh_hw_bios_cfg.md +++ /dev/null @@ -1,534 +0,0 @@ ---- -bookToc: true -title: "Huawei Taishan" ---- - -# Huawei Taishan - -## Linux lscpu - -``` -Architecture: aarch64 - CPU op-mode(s): 32-bit, 64-bit - Byte Order: Little Endian -CPU(s): 64 - On-line CPU(s) list: 0-63 -Vendor ID: ARM - Model name: Cortex-A72 - Model: 2 - Thread(s) per core: 1 - Core(s) per socket: 32 - Socket(s): 2 - Stepping: r0p2 - BogoMIPS: 100.00 - Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid -Caches (sum of all): - L1d: 2 MiB (64 instances) - L1i: 3 MiB (64 instances) - L2: 16 MiB (16 instances) - L3: 64 MiB (4 instances) -NUMA: - NUMA node(s): 4 - NUMA node0 CPU(s): 0-15 - NUMA node1 CPU(s): 16-31 - NUMA node2 CPU(s): 32-47 - NUMA node3 CPU(s): 48-63 -Vulnerabilities: - Itlb multihit: Not affected - L1tf: Not affected - Mds: Not affected - Meltdown: Not affected - Mmio stale data: Not affected - Retbleed: Not affected - Spec store bypass: Vulnerable - Spectre v1: Mitigation; __user pointer sanitization - Spectre v2: Vulnerable - Srbds: Not affected - Tsx async abort: Not affected -``` - -## Linux dmidecode - -``` -# dmidecode 3.3 -Getting SMBIOS data from sysfs. -SMBIOS 3.0.0 present. -Table at 0x39150000. - -Handle 0x0000, DMI type 0, 24 bytes -BIOS Information - Vendor: Huawei Corp. - Version: Estuary-5.1 D05 LTS - Release Date: 05/25/2018 - Address: 0xA4800 - Runtime Size: 366 kB - ROM Size: 3 MB - Characteristics: - PCI is supported - BIOS is upgradeable - BIOS shadowing is allowed - Boot from CD is supported - Selectable boot is supported - EDD is supported - Japanese floppy for NEC 9800 1.2 MB is supported (int 13h) - Japanese floppy for Toshiba 1.2 MB is supported (int 13h) - 5.25"/360 kB floppy services are supported (int 13h) - 5.25"/1.2 MB floppy services are supported (int 13h) - 3.5"/720 kB floppy services are supported (int 13h) - 3.5"/2.88 MB floppy services are supported (int 13h) - 8042 keyboard services are supported (int 9h) - CGA/mono video services are supported (int 10h) - ACPI is supported - USB legacy is supported - BIOS boot specification is supported - Targeted content distribution is supported - UEFI is supported - BIOS Revision: 0.0 - -Handle 0x0001, DMI type 1, 27 bytes -System Information - Manufacturer: Huawei - Product Name: D05 - Version: VER.A - Serial Number: 2102311TBJ10J1000089 - UUID: e11a0a38-f920-11e7-8c7d-a0a33bc11426 - Wake-up Type: Power Switch - SKU Number: To be filled by O.E.M. - Family: To be filled by O.E.M. - -Handle 0x0002, DMI type 3, 25 bytes -Chassis Information - Manufacturer: Huawei - Type: Main Server Chassis - Lock: Not Present - Version: To be filled by O.E.M. - Serial Number: To be filled by O.E.M. - Asset Tag: To be filled by O.E.M. - Boot-up State: Safe - Power Supply State: Safe - Thermal State: Safe - Security Status: None - OEM Information: 0x00000000 - Height: 2 U - Number Of Power Cords: 1 - Contained Elements: 0 - SKU Number: Not Specified - -Handle 0x0003, DMI type 2, 17 bytes -Base Board Information - Manufacturer: Huawei - Product Name: D05 - Version: Estuary - Serial Number: 024APL10H8000089 - Asset Tag: To be filled by O.E.M. - Features: - Board is a hosting board - Board is replaceable - Location In Chassis: To Be Filled By O.E.M. - Chassis Handle: 0x0002 - Type: Motherboard - Contained Object Handles: 0 -``` - -## Linux dmidecode memory - -``` -Handle 0x0007, DMI type 16, 23 bytes -Physical Memory Array - Location: System Board Or Motherboard - Use: System Memory - Error Correction Type: None - Maximum Capacity: 512 GB - Error Information Handle: Not Provided - Number Of Devices: 16 - -Handle 0x0009, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM000 J5 - Bank Locator: SOCKET 0 CHANNEL 0 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x37663087 - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x000A, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM001 J6 - Bank Locator: SOCKET 0 CHANNEL 0 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x000B, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM010 J8 - Bank Locator: SOCKET 0 CHANNEL 1 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x37663064 - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x000C, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM011 J9 - Bank Locator: SOCKET 0 CHANNEL 1 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x000D, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM020 J11 - Bank Locator: SOCKET 0 CHANNEL 2 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x3766308B - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x000E, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM021 J12 - Bank Locator: SOCKET 0 CHANNEL 2 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x000F, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM030 J14 - Bank Locator: SOCKET 0 CHANNEL 3 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x376630DA - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x0010, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM031 J15 - Bank Locator: SOCKET 0 CHANNEL 3 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x0011, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM100 J17 - Bank Locator: SOCKET 1 CHANNEL 0 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x379A2774 - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x0012, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM101 J18 - Bank Locator: SOCKET 1 CHANNEL 0 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x0013, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM110 J20 - Bank Locator: SOCKET 1 CHANNEL 1 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x3766308A - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x0014, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM111 J21 - Bank Locator: SOCKET 1 CHANNEL 1 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x0015, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM120 J23 - Bank Locator: SOCKET 1 CHANNEL 2 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x376630B0 - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x0016, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM121 J24 - Bank Locator: SOCKET 1 CHANNEL 2 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown - -Handle 0x0017, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16 GB - Form Factor: DIMM - Set: None - Locator: DIMM130 J26 - Bank Locator: SOCKET 1 CHANNEL 3 DIMM 0 - Type: DDR4 - Type Detail: Synchronous Registered (Buffered) - Speed: 2400 MT/s - Manufacturer: Samsung - Serial Number: 0x376630A0 - Asset Tag: Unknown - Part Number: M393A2K43BB1-CRC - Rank: 2 - Configured Memory Speed: 2400 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 2.0 V - Configured Voltage: 1.2 V - -Handle 0x0018, DMI type 17, 40 bytes -Memory Device - Array Handle: 0x0007 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: DIMM131 J27 - Bank Locator: SOCKET 1 CHANNEL 3 DIMM 1 - Type: Unknown - Type Detail: Unknown Synchronous - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Memory Speed: Unknown - Minimum Voltage: Unknown - Maximum Voltage: Unknown - Configured Voltage: Unknown -``` - -## Linux cmdline - -``` -BOOT_IMAGE=/boot/vmlinuz-5.4.0-65-generic root=UUID=7d1d0e77-4df0-43df-9619-a99db29ffb83 ro audit=0 intel_iommu=on isolcpus=1-27,29-55 nmi_watchdog=0 nohz_full=1-27,29-55 nosoftlockup processor.max_cstate=1 rcu_nocbs=1-27,29-55 console=ttyAMA0,115200n8 quiet -``` diff --git a/docs/content/infrastructure/testbed_configuration/sm_clx_hw_bios_cfg.md b/docs/content/infrastructure/testbed_configuration/sm_clx_hw_bios_cfg.md deleted file mode 100644 index c955b424fe..0000000000 --- a/docs/content/infrastructure/testbed_configuration/sm_clx_hw_bios_cfg.md +++ /dev/null @@ -1,1425 +0,0 @@ ---- -bookToc: true -title: "SuperMicro Cascadelake" ---- - -# SuperMicro Cascadelake - -## Linux lscpu - -``` -Architecture: x86_64 -CPU op-mode(s): 32-bit, 64-bit -Byte Order: Little Endian -CPU(s): 112 -On-line CPU(s) list: 0-111 -Thread(s) per core: 2 -Core(s) per socket: 28 -Socket(s): 2 -NUMA node(s): 2 -Vendor ID: GenuineIntel -CPU family: 6 -Model: 85 -Model name: Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz -Stepping: 7 -CPU MHz: 3299.609 -BogoMIPS: 5400.00 -Virtualization: VT-x -L1d cache: 32K -L1i cache: 32K -L2 cache: 1024K -L3 cache: 39424K -NUMA node0 CPU(s): 0-27,56-83 -NUMA node1 CPU(s): 28-55,84-111 -Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca -cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx -pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology -nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est -tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt -tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch -cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp -ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 -hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx -smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 -xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts -pku ospke avx512_vnni md_clear flush_l1d arch_capabilities -``` - -``` -Architecture: x86_64 -CPU op-mode(s): 32-bit, 64-bit -Byte Order: Little Endian -CPU(s): 96 -On-line CPU(s) list: 0-95 -Thread(s) per core: 2 -Core(s) per socket: 24 -Socket(s): 2 -NUMA node(s): 2 -Vendor ID: GenuineIntel -CPU family: 6 -Model: 85 -Model name: Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz -Stepping: 7 -CPU MHz: 3000.989 -BogoMIPS: 4600.00 -Virtualization: VT-x -L1d cache: 32K -L1i cache: 32K -L2 cache: 1024K -L3 cache: 36608K -NUMA node0 CPU(s): 0-23,48-71 -NUMA node1 CPU(s): 24-47,72-95 -Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca -cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx -pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology -nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 -ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt -tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch -cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp -ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle -avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap -clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 -xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts -pku ospke avx512_vnni md_clear flush_l1d arch_capabilities -``` - -## Linux dmidecode - -``` - # dmidecode 3.1 - Getting SMBIOS data from sysfs. - SMBIOS 3.1.2 present. - Table at 0x6EB92000. - - Handle 0x0000, DMI type 0, 26 bytes - BIOS Information - Vendor: American Megatrends Inc. - Version: 3.0c - Release Date: 03/27/2019 - Address: 0xF0000 - Runtime Size: 64 kB - ROM Size: 32 MB - Characteristics: - PCI is supported - BIOS is upgradeable - BIOS shadowing is allowed - Boot from CD is supported - Selectable boot is supported - BIOS ROM is socketed - EDD is supported - 5.25"/1.2 MB floppy services are supported (int 13h) - 3.5"/720 kB floppy services are supported (int 13h) - 3.5"/2.88 MB floppy services are supported (int 13h) - Print screen service is supported (int 5h) - Serial services are supported (int 14h) - Printer services are supported (int 17h) - ACPI is supported - USB legacy is supported - BIOS boot specification is supported - Targeted content distribution is supported - UEFI is supported - BIOS Revision: 5.14 - - Handle 0x0001, DMI type 1, 27 bytes - System Information - Manufacturer: Supermicro - Product Name: SYS-7049GP-TRT - Version: 0123456789 - Serial Number: S291427X9525476 - UUID: 00000000-0000-0000-0000-AC1F6BACD7BA - Wake-up Type: Power Switch - SKU Number: To be filled by O.E.M. - Family: To be filled by O.E.M. - - Handle 0x0002, DMI type 2, 15 bytes - Base Board Information - Manufacturer: Supermicro - Product Name: X11DPG-QT - Version: 1.10A - Serial Number: VM189S007860 - Asset Tag: To be filled by O.E.M. - Features: - Board is a hosting board - Board is replaceable - Location In Chassis: To be filled by O.E.M. - Chassis Handle: 0x0003 - Type: Motherboard - Contained Object Handles: 0 - - Handle 0x0003, DMI type 3, 22 bytes - Chassis Information - Manufacturer: Supermicro - Type: Other - Lock: Not Present - Version: 0123456789 - Serial Number: C7470KH37A30566 - Asset Tag: To be filled by O.E.M. - Boot-up State: Safe - Power Supply State: Safe - Thermal State: Safe - Security Status: None - OEM Information: 0x00000000 - Height: Unspecified - Number Of Power Cords: 1 - Contained Elements: 0 - SKU Number: To be filled by O.E.M. - - Handle 0x0055, DMI type 4, 48 bytes - Processor Information - Socket Designation: CPU1 - Type: Central Processor - Family: Xeon - Manufacturer: Intel(R) Corporation - ID: 57 06 05 00 FF FB EB BF - Signature: Type 0, Family 6, Model 85, Stepping 7 - Flags: - FPU (Floating-point unit on-chip) - VME (Virtual mode extension) - DE (Debugging extension) - PSE (Page size extension) - TSC (Time stamp counter) - MSR (Model specific registers) - PAE (Physical address extension) - MCE (Machine check exception) - CX8 (CMPXCHG8 instruction supported) - APIC (On-chip APIC hardware supported) - SEP (Fast system call) - MTRR (Memory type range registers) - PGE (Page global enable) - MCA (Machine check architecture) - CMOV (Conditional move instruction supported) - PAT (Page attribute table) - PSE-36 (36-bit page size extension) - CLFSH (CLFLUSH instruction supported) - DS (Debug store) - ACPI (ACPI supported) - MMX (MMX technology supported) - FXSR (FXSAVE and FXSTOR instructions supported) - SSE (Streaming SIMD extensions) - SSE2 (Streaming SIMD extensions 2) - SS (Self-snoop) - HTT (Multi-threading) - TM (Thermal monitor supported) - PBE (Pending break enabled) - Version: Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz - Voltage: 1.6 V - External Clock: 100 MHz - Max Speed: 4500 MHz - Current Speed: 2300 MHz - Status: Populated, Enabled - Upgrade: Socket LGA3647-1 - L1 Cache Handle: 0x0052 - L2 Cache Handle: 0x0053 - L3 Cache Handle: 0x0054 - Serial Number: Not Specified - Asset Tag: UNKNOWN - Part Number: Not Specified - Core Count: 24 - Core Enabled: 24 - Thread Count: 48 - Characteristics: - 64-bit capable - Multi-Core - Hardware Thread - Execute Protection - Enhanced Virtualization - Power/Performance Control - - Handle 0x0059, DMI type 4, 48 bytes - Processor Information - Socket Designation: CPU2 - Type: Central Processor - Family: Xeon - Manufacturer: Intel(R) Corporation - ID: 57 06 05 00 FF FB EB BF - Signature: Type 0, Family 6, Model 85, Stepping 7 - Flags: - FPU (Floating-point unit on-chip) - VME (Virtual mode extension) - DE (Debugging extension) - PSE (Page size extension) - TSC (Time stamp counter) - MSR (Model specific registers) - PAE (Physical address extension) - MCE (Machine check exception) - CX8 (CMPXCHG8 instruction supported) - APIC (On-chip APIC hardware supported) - SEP (Fast system call) - MTRR (Memory type range registers) - PGE (Page global enable) - MCA (Machine check architecture) - CMOV (Conditional move instruction supported) - PAT (Page attribute table) - PSE-36 (36-bit page size extension) - CLFSH (CLFLUSH instruction supported) - DS (Debug store) - ACPI (ACPI supported) - MMX (MMX technology supported) - FXSR (FXSAVE and FXSTOR instructions supported) - SSE (Streaming SIMD extensions) - SSE2 (Streaming SIMD extensions 2) - SS (Self-snoop) - HTT (Multi-threading) - TM (Thermal monitor supported) - PBE (Pending break enabled) - Version: Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz - Voltage: 1.6 V - External Clock: 100 MHz - Max Speed: 4500 MHz - Current Speed: 2300 MHz - Status: Populated, Enabled - Upgrade: Socket LGA3647-1 - L1 Cache Handle: 0x0056 - L2 Cache Handle: 0x0057 - L3 Cache Handle: 0x0058 - Serial Number: Not Specified - Asset Tag: UNKNOWN - Part Number: Not Specified - Core Count: 24 - Core Enabled: 24 - Thread Count: 48 - Characteristics: - 64-bit capable - Multi-Core - Hardware Thread - Execute Protection - Enhanced Virtualization - Power/Performance Control -``` - -## Linux dmidecode pci - -``` - Handle 0x000B, DMI type 9, 17 bytes - System Slot Information - Designation: CPU1 SLOT2 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: In Use - Length: Long - ID: 2 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:18:00.0 - - Handle 0x000C, DMI type 9, 17 bytes - System Slot Information - Designation: CPU1 SLOT4 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: In Use - Length: Short - ID: 4 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:3b:00.0 - - Handle 0x000D, DMI type 9, 17 bytes - System Slot Information - Designation: CPU2 SLOT6 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: Available - Length: Short - ID: 6 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 - - Handle 0x000E, DMI type 9, 17 bytes - System Slot Information - Designation: CPU2 SLOT8 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: Available - Length: Short - ID: 8 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 - - Handle 0x000F, DMI type 9, 17 bytes - System Slot Information - Designation: CPU1 SLOT9 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: Available - Length: Short - ID: 9 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 - - Handle 0x0010, DMI type 9, 17 bytes - System Slot Information - Designation: CPU2 SLOT10 PCI-E 3.0 X16 - Type: x16 PCI Express 3 x16 - Current Usage: Available - Length: Short - ID: 10 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 - - Handle 0x0011, DMI type 9, 17 bytes - System Slot Information - Designation: CPU2 SLOT11 PCI-E 3.0 X4(IN X8) - Type: x4 PCI Express 3 x8 - Current Usage: Available - Length: Short - ID: 11 - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 - - Handle 0x0012, DMI type 9, 17 bytes - System Slot Information - Designation: M.2 CONNECTOR - Type: x4 M.2 Socket 2 - Current Usage: Available - Length: Short - Characteristics: - 3.3 V is provided - Opening is shared - PME signal is supported - Bus Address: 0000:ff:00.0 -``` - -## Linux dmidecode memory - -``` - Handle 0x0023, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0021 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMMA1 - Bank Locator: P0_Node0_Channel0_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F0E - Asset Tag: P1-DIMMA1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0024, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0021 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: P1-DIMMA2 - Bank Locator: P0_Node0_Channel0_Dimm1 - Type: Unknown - Type Detail: Unknown - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Clock Speed: Unknown - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0025, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0021 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMMB1 - Bank Locator: P0_Node0_Channel1_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F1F - Asset Tag: P1-DIMMB1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0027, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0021 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMMC1 - Bank Locator: P0_Node0_Channel2_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F07 - Asset Tag: P1-DIMMC1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x002B, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0029 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMMD1 - Bank Locator: P0_Node1_Channel0_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F02 - Asset Tag: P1-DIMMD1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x002C, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0029 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: P1-DIMMD2 - Bank Locator: P0_Node1_Channel0_Dimm1 - Type: Unknown - Type Detail: Unknown - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Clock Speed: Unknown - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x002D, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0029 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMME1 - Bank Locator: P0_Node1_Channel1_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F19 - Asset Tag: P1-DIMME1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x002F, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0029 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P1-DIMMF1 - Bank Locator: P0_Node1_Channel2_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275FD3 - Asset Tag: P1-DIMMF1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0031, DMI type 16, 23 bytes - Physical Memory Array - Location: System Board Or Motherboard - Use: System Memory - Error Correction Type: Single-bit ECC - Maximum Capacity: 2304 GB - Error Information Handle: Not Provided - Number Of Devices: 4 - - Handle 0x0033, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0031 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMMA1 - Bank Locator: P1_Node0_Channel0_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275FE2 - Asset Tag: P2-DIMMA1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0034, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0031 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: P2-DIMMA2 - Bank Locator: P1_Node0_Channel0_Dimm1 - Type: Unknown - Type Detail: Unknown - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Clock Speed: Unknown - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0035, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0031 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMMB1 - Bank Locator: P1_Node0_Channel1_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93276001 - Asset Tag: P2-DIMMB1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0037, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0031 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMMC1 - Bank Locator: P1_Node0_Channel2_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93276005 - Asset Tag: P2-DIMMC1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x0039, DMI type 16, 23 bytes - Physical Memory Array - Location: System Board Or Motherboard - Use: System Memory - Error Correction Type: Single-bit ECC - Maximum Capacity: 2304 GB - Error Information Handle: Not Provided - Number Of Devices: 4 - - Handle 0x003B, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0039 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMMD1 - Bank Locator: P1_Node1_Channel0_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275F44 - Asset Tag: P2-DIMMD1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x003C, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0039 - Error Information Handle: Not Provided - Total Width: Unknown - Data Width: Unknown - Size: No Module Installed - Form Factor: DIMM - Set: None - Locator: P2-DIMMD2 - Bank Locator: P1_Node1_Channel0_Dimm1 - Type: Unknown - Type Detail: Unknown - Speed: Unknown - Manufacturer: NO DIMM - Serial Number: NO DIMM - Asset Tag: NO DIMM - Part Number: NO DIMM - Rank: Unknown - Configured Clock Speed: Unknown - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x003D, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0039 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMME1 - Bank Locator: P1_Node1_Channel1_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275FDF - Asset Tag: P2-DIMME1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V - - Handle 0x003F, DMI type 17, 84 bytes - Memory Device - Array Handle: 0x0039 - Error Information Handle: Not Provided - Total Width: 72 bits - Data Width: 64 bits - Size: 16384 MB - Form Factor: DIMM - Set: None - Locator: P2-DIMMF1 - Bank Locator: P1_Node1_Channel2_Dimm0 - Type: DDR4 - Type Detail: Synchronous - Speed: 2933 MT/s - Manufacturer: SK Hynix - Serial Number: 93275FDD - Asset Tag: P2-DIMMF1_AssetTag (date:19/22) - Part Number: HMA82GR7CJR8N-WM - Rank: 2 - Configured Clock Speed: 2934 MT/s - Minimum Voltage: 1.2 V - Maximum Voltage: 1.2 V - Configured Voltage: 1.2 V -``` - -## Xeon CLX Server BIOS Configuration - TG - -### Boot Feature - -``` - | Quiet Boot [Enabled] |Boot option | - | | | - | Option ROM Messages [Force BIOS] | | - | Bootup NumLock State [On] | | - | Wait For "F1" If Error [Enabled] | | - | INT19 Trap Response [Immediate] | | - | Re-try Boot [Disabled] | | - | Install Windows 7 USB support [Disabled] | | - | Port 61h Bit-4 Emulation [Disabled] | | - | | | - | Power Configuration | | - | Watch Dog Function [Disabled] | | - | Restore on AC Power Loss [Last State] | | - | Power Button Function [Instant Off] | | -``` - -### CPU Configuration - -``` - | Processor Configuration ^|Enables Hyper Threading | - | -------------------------------------------------- *|(Software Method to | - | Processor BSP Revision 50657 - CLX B1 *|Enable/Disable Logical | - | Processor Socket CPU1 | CPU2 *|Processor threads. | - | Processor ID 00050657* | 00050657 *| | - | Processor Frequency 2.700GHz | 2.700GHz *| | - | Processor Max Ratio 1BH | 1BH *| | - | Processor Min Ratio 0AH | 0AH *| | - | Microcode Revision 0500002C | 0500002C *| | - | L1 Cache RAM 64KB | 64KB *| | - | L2 Cache RAM 1024KB | 1024KB *| | - | L3 Cache RAM 39424KB | 39424KB *| | - | Processor 0 Version *| | - | Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz *| | - | Processor 1 Version *| | - | Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz *| | - | *|-----------------------------| - | Hyper-Threading [ALL] [Enable] *|><: Select Screen | - | Cores Enabled 0 *|^v: Select Item | - | Monitor/Mwait [Auto] *|Enter: Select | - | Execute Disable Bit [Enable] +|+/-: Change Opt. | - | Intel Virtualization Technology [Enable] +|F1: General Help | - | PPIN Control [Unlock/Enable] +|F2: Previous Values | - | Hardware Prefetcher [Enable] +|F3: Optimized Defaults | - | Adjacent Cache Prefetch [Enable] v|F4: Save & Exit | - | DCU Streamer Prefetcher [Enable] | | - | DCU IP Prefetcher [Enable] | | - | LLC Prefetch [Disable] | | - | Extended APIC [Disable] | | - | AES-NI [Enable] | | - |> Advanced Power Management Configuration | | -``` - -#### Advanced Power Management Configuration - -``` - | Advanced Power Management Configuration |Switch CPU Power Management | - | -------------------------------------------------- |profile | - | Power Technology [Custom] | | - | Power Performance Tuning [BIOS Controls EPB] | | - | ENERGY_PERF_BIAS_CFG mode [Maximum Performance] | | - |> CPU P State Control | | - |> Hardware PM State Control | | - |> CPU C State Control | | - |> Package C State Control | | - |> CPU T State Control | | -``` - -##### CPU P State Control - -``` - | CPU P State Control |EIST allows the processor | - | |to dynamically adjust | - | SpeedStep (P-States) [Disable] |frequency and voltage based | - | EIST PSD Function [HW_ALL] |on power versus performance | - | |needs. | - | | | -``` - -##### Hardware PM State Control - -``` - | Hardware PM State Control |If set to Disable, hardware ^| - | |will choose a P-state *| - | Hardware P-States [Disable] |setting for the system *| - | |based on an OS request. *| - | |If set to Native Mode, *| - | |hardware will choose a *| - | |P-state setting based on OS *| - | |guidance. *| - | |If set to Native Mode with *| - | |No Legacy Support, hardware *| - | |will choose a P-state *| - | |setting independently *| - | |without OS guidance. +| - | |If set to Out of Band Mode, +| - | |hardware autonomously v| -``` - -##### CPU C State Control - -``` - | CPU C State Control |Select Enable to support | - | |Autonomous Core C-State | - | Autonomous Core C-State [Disable] |control which will allow | - | CPU C6 report [Disable] |the processor core to | - | Enhanced Halt State (C1E) [Disable] |control its C-State setting | - | |automatically and | - | |independently. | -``` - -##### Package C State Control - -``` - | Package C State Control |Limit the lowest package | - | |level C-State to | - | Package C State [C0/C1 state] |processors. Lower package | - | |C-State lower processor | - | |power consumption upon idle. | -``` - -##### CPU T State Control - -``` - | CPU T State Control |Enable/Disable CPU | - | |throttling by OS. | - | Software Controlled T-States [Disable] |Throttling reduces power | - | |consumption | -``` - -#### Chipset Configuration - -``` - | WARNING: Setting wrong values in below sections may cause |North Bridge Parameters | - | system to malfunction. | | - |> North Bridge | | - |> South Bridge | | -``` - -##### North Bridge - -``` - |> UPI Configuration |Displays and provides | - |> Memory Configuration |option to change the UPI | - |> IIO Configuration |Settings | -``` - -##### UPI Configuration - -``` - | UPI Configuration |Use this feature to select | - | -------------------------------------------------- |the degrading precedence | - | Number of CPU 2 |option for Ultra Path | - | Number of Active UPI Link 3 |Interconnect connections. | - | Current UPI Link Speed Fast |Select Topology Precedent | - | Current UPI Link Frequency 10.4 GT/s |to degrade UPI features if | - | UPI Global MMIO Low Base / Limit 90000000 / FBFFFFFF |system options are in | - | UPI Global MMIO High Base / Limit 0000000000000000 / |conflict. Select Feature | - | 00000000FFFFFFFF |Precedent to degrade UPI | - | UPI Pci-e Configuration Base / Size 80000000 / 10000000 |topology if system options | - | Degrade Precedence [Topology Precedence] |are in conflict. | - | Link L0p Enable [Disable] | | - | Link L1 Enable [Disable] | | - | IO Directory Cache (IODC) [Auto] | | - | SNC [Disable] | | - | XPT Prefetch [Disable] | | - | KTI Prefetch [Enable] |-----------------------------| - | Local/Remote Threshold [Auto] |><: Select Screen | - | Stale AtoS [Auto] |^v: Select Item | - | LLC Dead Line Alloc [Enable] |Enter: Select | - | Isoc Mode [Auto] |+/-: Change Opt. | -``` - -##### Memory Configuration - -``` - | |Select POR to enforce POR | - | -------------------------------------------------- |restrictions for DDR4 | - | Integrated Memory Controller (iMC) |frequency and voltage | - | -------------------------------------------------- |programming | - | | | - | Enforce POR [POR] | | - | PPR Type [Hard PPR] | | - | Enhanced PPR [Disable] | | - | Operation Mode [Test and Repair] | | - | Memory Frequency [2933] | | - | Data Scrambling for DDR4 [Auto] | | - | tCCD_L Relaxation [Auto] | | - | tRWSR Relaxation [Disable] | | - | tRFC Optimization for 16Gb Based DIMM [Force 550ns] | | - | 2x Refresh [Auto] | | - | Page Policy [Auto] | | - | IMC Interleaving [2-way Interleave] |-----------------------------| - |> Memory Topology |><: Select Screen | - |> Memory RAS Configuration |^v: Select Item | -``` - -##### IIO Configuration - -``` - | IIO Configuration |Expose IIO DFX devices and | - | -------------------------------------------------- |other CPU devices like PMON | - | | | - | EV DFX Features [Disable] | | - |> CPU1 Configuration | | - |> CPU2 Configuration | | - |> IOAT Configuration | | - |> Intel. VT for Directed I/O (VT-d) | | - |> Intel. VMD technology | | - | | | - | IIO-PCIE Express Global Options | | - | ======================================== | | - | PCI-E Completion Timeout Disable [No] | | -``` - -##### CPU1 Configuration - -``` - | IOU0 (IIO PCIe Br1) [Auto] |Selects PCIe port | - | IOU1 (IIO PCIe Br2) [Auto] |Bifurcation for selected | - | IOU2 (IIO PCIe Br3) [Auto] |slot(s) | - |> CPU1 SLOT2 PCI-E 3.0 X16 | | - |> CPU1 SLOT4 PCI-E 3.0 X16 | | - |> CPU1 SLOT9 PCI-E 3.0 X16 | | -``` - -##### CPU2 Configuration - -``` - | IOU0 (IIO PCIe Br1) [Auto] |Selects PCIe port | - | IOU1 (IIO PCIe Br2) [Auto] |Bifurcation for selected | - | IOU2 (IIO PCIe Br3) [Auto] |slot(s) | - |> CPU2 SLOT6 PCI-E 3.0 X16 | | - |> CPU2 SLOT8 PCI-E 3.0 X16 | | - |> CPU2 SLOT10 PCI-E 3.0 X16 | | -``` - -#### South Bridge - -``` - | |Enables Legacy USB support. | - | USB Module Version 21 |AUTO option disables legacy | - | |support if no USB devices | - | USB Devices: |are connected. DISABLE | - | 1 Keyboard, 1 Mouse, 1 Hub |option will keep USB | - | |devices available only for | - | Legacy USB Support [Enabled] |EFI applications. | - | XHCI Hand-off [Enabled] | | - | Port 60/64 Emulation [Enabled] | | - | PCIe PLL SSC [Disable] | | - | Real USB Wake Up [Enabled] | | - | Front USB Wake Up [Enabled] | | - | | | - | Azalia [Auto] | | - | Azalia PME Enable [Disabled] | | -``` - -### PCIe/PCI/PnP Configuration - -``` - | PCI Bus Driver Version A5.01.18 ^|Enables or Disables 64bit | - | *|capable Devices to be | - | PCI Devices Common Settings: *|Decoded in Above 4G Address | - | Above 4G Decoding [Enabled] *|Space (Only if System | - | SR-IOV Support [Enabled] *|Supports 64 bit PCI | - | ARI Support [Enabled] *|Decoding). | - | MMIO High Base [56T] *| | - | MMIO High Granularity Size [256G] *| | - | Maximum Read Request [Auto] *| | - | MMCFG Base [2G] *| | - | NVMe Firmware Source [Vendor Defined *| | - | Firmware] *| | - | VGA Priority [Onboard] *| | - | CPU1 SLOT2 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU1 SLOT4 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU2 SLOT6 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU2 SLOT8 PCI-E 3.0 X16 OPROM [Legacy] *|-----------------------------| - | CPU1 SLOT9 PCI-E 3.0 X16 OPROM [Legacy] *|><: Select Screen | - | CPU2 SLOT10 PCI-E 3.0 X16 OPROM [Legacy] *|^v: Select Item | - | CPU2 SLOT11 PCI-E 3.0 X4(IN X8) OPROM [Legacy] *|Enter: Select | - | M.2 CONNECTOR OPROM [Legacy] *|+/-: Change Opt. | - | Bus Master Enable [Enabled] +|F1: General Help | - | Onboard LAN1 Option ROM [Legacy] +|F2: Previous Values | - | Onboard LAN2 Option ROM [Disabled] +|F3: Optimized Defaults | - | Onboard Video Option ROM [Legacy] v|F4: Save & Exit | - |> Network Stack Configuration | | -``` - -### ACPI Settings - -``` - | ACPI Settings |Enable or Disable Non | - | |uniform Memory Access | - | NUMA [Enabled] |(NUMA). | - | WHEA Support [Enabled] | | - | High Precision Event Timer [Enabled] | | -``` - -## Xeon CLX Server BIOS Configuration - DUT - -### Boot Feature - -``` - | Quiet Boot [Enabled] |Boot option | - | | | - | Option ROM Messages [Force BIOS] | | - | Bootup NumLock State [On] | | - | Wait For "F1" If Error [Enabled] | | - | INT19 Trap Response [Immediate] | | - | Re-try Boot [Disabled] | | - | Install Windows 7 USB support [Disabled] | | - | Port 61h Bit-4 Emulation [Disabled] | | - | | | - | Power Configuration | | - | Watch Dog Function [Disabled] | | - | Restore on AC Power Loss [Last State] | | - | Power Button Function [Instant Off] | | -``` - -### CPU Configuration - -``` - |--------------------------------------------------------------------+-----------------------------\ - | Processor Configuration ^|Enables Hyper Threading | - | -------------------------------------------------- *|(Software Method to | - | Processor BSP Revision 50657 - CLX B1 *|Enable/Disable Logical | - | Processor Socket CPU1 | CPU2 *|Processor threads. | - | Processor ID 00050657* | 00050657 *| | - | Processor Frequency 2.300GHz | 2.300GHz *| | - | Processor Max Ratio 17H | 17H *| | - | Processor Min Ratio 0AH | 0AH *| | - | Microcode Revision 0500002C | 0500002C *| | - | L1 Cache RAM 64KB | 64KB *| | - | L2 Cache RAM 1024KB | 1024KB *| | - | L3 Cache RAM 36608KB | 36608KB *| | - | Processor 0 Version *| | - | Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz *| | - | Processor 1 Version *| | - | Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz *| | - | *|-----------------------------| - | Hyper-Threading [ALL] [Enable] *|><: Select Screen | - | Cores Enabled 0 *|^v: Select Item | - | Monitor/Mwait [Auto] *|Enter: Select | - | Execute Disable Bit [Enable] +|+/-: Change Opt. | - | Intel Virtualization Technology [Enable] +|F1: General Help | - | PPIN Control [Unlock/Enable] +|F2: Previous Values | - | Hardware Prefetcher [Enable] +|F3: Optimized Defaults | - | Adjacent Cache Prefetch [Enable] v|F4: Save & Exit | - | DCU Streamer Prefetcher [Enable] | | - | DCU IP Prefetcher [Enable] | | - | LLC Prefetch [Disable] | | - | Extended APIC [Disable] | | - | AES-NI [Enable] | | - |> Advanced Power Management Configuration | | -``` - -#### Advanced Power Management Configuration - -``` - | Advanced Power Management Configuration |Switch CPU Power Management | - | -------------------------------------------------- |profile | - | Power Technology [Custom] | | - | Power Performance Tuning [BIOS Controls EPB] | | - | ENERGY_PERF_BIAS_CFG mode [Maximum Performance] | | - |> CPU P State Control | | - |> Hardware PM State Control | | - |> CPU C State Control | | - |> Package C State Control | | - |> CPU T State Control | | -``` - -##### CPU P State Control - -``` - | CPU P State Control |EIST allows the processor | - | |to dynamically adjust | - | SpeedStep (P-States) [Disable] |frequency and voltage based | - | Activate PBF [Disable] |on power versus performance | - | Configure PBF [Enable] |needs. | - | EIST PSD Function [HW_ALL] | | -``` - -##### Hardware PM State Control - -``` - | Hardware PM State Control |If set to Disable, hardware ^| - | |will choose a P-state *| - | Hardware P-States [Disable] |setting for the system *| - | |based on an OS request. *| - | |If set to Native Mode, *| - | |hardware will choose a *| - | |P-state setting based on OS *| - | |guidance. *| - | |If set to Native Mode with *| - | |No Legacy Support, hardware *| - | |will choose a P-state *| - | |setting independently *| - | |without OS guidance. +| - | |If set to Out of Band Mode, +| - | |hardware autonomously v| -``` - -##### CPU C State Control - -``` - | CPU C State Control |Select Enable to support | - | |Autonomous Core C-State | - | Autonomous Core C-State [Disable] |control which will allow | - | CPU C6 report [Disable] |the processor core to | - | Enhanced Halt State (C1E) [Disable] |control its C-State setting | - | |automatically and | - | |independently. | -``` - -##### Package C State Control - -``` - | Package C State Control |Limit the lowest package | - | |level C-State to | - | Package C State [C0/C1 state] |processors. Lower package | - | |C-State lower processor | - | |power consumption upon idle. | -``` - -##### CPU T State Control - -``` - | CPU T State Control |Enable/Disable CPU | - | |throttling by OS. | - | Software Controlled T-States [Disable] |Throttling reduces power | - | |consumption | -``` - -#### Chipset Configuration - -``` - | WARNING: Setting wrong values in below sections may cause |North Bridge Parameters | - | system to malfunction. | | - |> North Bridge | | - |> South Bridge | | -``` - -##### North Bridge - -``` - |> UPI Configuration |Displays and provides | - |> Memory Configuration |option to change the UPI | - |> IIO Configuration |Settings | -``` - -##### UPI Configuration - -``` - | UPI Configuration |Use this feature to select | - | -------------------------------------------------- |the degrading precedence | - | Number of CPU 2 |option for Ultra Path | - | Number of Active UPI Link 3 |Interconnect connections. | - | Current UPI Link Speed Fast |Select Topology Precedent | - | Current UPI Link Frequency 10.4 GT/s |to degrade UPI features if | - | UPI Global MMIO Low Base / Limit 90000000 / FBFFFFFF |system options are in | - | UPI Global MMIO High Base / Limit 0000000000000000 / |conflict. Select Feature | - | 00000000FFFFFFFF |Precedent to degrade UPI | - | UPI Pci-e Configuration Base / Size 80000000 / 10000000 |topology if system options | - | Degrade Precedence [Topology Precedence] |are in conflict. | - | Link L0p Enable [Disable] | | - | Link L1 Enable [Disable] | | - | IO Directory Cache (IODC) [Auto] | | - | SNC [Disable] | | - | XPT Prefetch [Disable] | | - | KTI Prefetch [Enable] |-----------------------------| - | Local/Remote Threshold [Auto] |><: Select Screen | - | Stale AtoS [Auto] |^v: Select Item | - | LLC Dead Line Alloc [Enable] |Enter: Select | - | Isoc Mode [Auto] |+/-: Change Opt. | -``` - -##### Memory Configuration - -``` - | |Select POR to enforce POR | - | -------------------------------------------------- |restrictions for DDR4 | - | Integrated Memory Controller (iMC) |frequency and voltage | - | -------------------------------------------------- |programming | - | | | - | Enforce POR [POR] | | - | PPR Type [Hard PPR] | | - | Enhanced PPR [Disable] | | - | Operation Mode [Test and Repair] | | - | Memory Frequency [2933] | | - | Data Scrambling for DDR4 [Auto] | | - | tCCD_L Relaxation [Auto] | | - | tRWSR Relaxation [Disable] | | - | tRFC Optimization for 16Gb Based DIMM [Force 550ns] | | - | 2x Refresh [Auto] | | - | Page Policy [Auto] | | - | IMC Interleaving [2-way Interleave] |-----------------------------| - |> Memory Topology |><: Select Screen | - |> Memory RAS Configuration |^v: Select Item | -``` - -##### IIO Configuration - -``` - | IIO Configuration |Expose IIO DFX devices and | - | -------------------------------------------------- |other CPU devices like PMON | - | | | - | EV DFX Features [Disable] | | - |> CPU1 Configuration | | - |> CPU2 Configuration | | - |> IOAT Configuration | | - |> Intel. VT for Directed I/O (VT-d) | | - |> Intel. VMD technology | | - | | | - | IIO-PCIE Express Global Options | | - | ======================================== | | - | PCI-E Completion Timeout Disable [No] | | -``` - -##### CPU1 Configuration - -``` - | IOU0 (IIO PCIe Br1) [Auto] |Selects PCIe port | - | IOU1 (IIO PCIe Br2) [Auto] |Bifurcation for selected | - | IOU2 (IIO PCIe Br3) [Auto] |slot(s) | - |> CPU1 SLOT2 PCI-E 3.0 X16 | | - |> CPU1 SLOT4 PCI-E 3.0 X16 | | - |> CPU1 SLOT9 PCI-E 3.0 X16 | | -``` - -##### CPU2 Configuration - -``` - | IOU0 (IIO PCIe Br1) [Auto] |Selects PCIe port | - | IOU1 (IIO PCIe Br2) [Auto] |Bifurcation for selected | - | IOU2 (IIO PCIe Br3) [Auto] |slot(s) | - |> CPU2 SLOT6 PCI-E 3.0 X16 | | - |> CPU2 SLOT8 PCI-E 3.0 X16 | | - |> CPU2 SLOT10 PCI-E 3.0 X16 | | -``` - -#### South Bridge - -``` - | |Enables Legacy USB support. | - | USB Module Version 21 |AUTO option disables legacy | - | |support if no USB devices | - | USB Devices: |are connected. DISABLE | - | 1 Keyboard, 1 Mouse, 1 Hub |option will keep USB | - | |devices available only for | - | Legacy USB Support [Enabled] |EFI applications. | - | XHCI Hand-off [Enabled] | | - | Port 60/64 Emulation [Enabled] | | - | PCIe PLL SSC [Disable] | | - | Real USB Wake Up [Enabled] | | - | Front USB Wake Up [Enabled] | | - | | | - | Azalia [Auto] | | - | Azalia PME Enable [Disabled] | | -``` - -### PCIe/PCI/PnP Configuration - -``` - | PCI Bus Driver Version A5.01.18 ^|Enables or Disables 64bit | - | *|capable Devices to be | - | PCI Devices Common Settings: *|Decoded in Above 4G Address | - | Above 4G Decoding [Enabled] *|Space (Only if System | - | SR-IOV Support [Enabled] *|Supports 64 bit PCI | - | ARI Support [Enabled] *|Decoding). | - | MMIO High Base [56T] *| | - | MMIO High Granularity Size [256G] *| | - | Maximum Read Request [Auto] *| | - | MMCFG Base [2G] *| | - | NVMe Firmware Source [Vendor Defined *| | - | Firmware] *| | - | VGA Priority [Onboard] *| | - | CPU1 SLOT2 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU1 SLOT4 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU2 SLOT6 PCI-E 3.0 X16 OPROM [Legacy] *| | - | CPU2 SLOT8 PCI-E 3.0 X16 OPROM [Legacy] *|-----------------------------| - | CPU1 SLOT9 PCI-E 3.0 X16 OPROM [Legacy] *|><: Select Screen | - | CPU2 SLOT10 PCI-E 3.0 X16 OPROM [Legacy] *|^v: Select Item | - | CPU2 SLOT11 PCI-E 3.0 X4(IN X8) OPROM [Legacy] *|Enter: Select | - | M.2 CONNECTOR OPROM [Legacy] *|+/-: Change Opt. | - | Bus Master Enable [Enabled] +|F1: General Help | - | Onboard LAN1 Option ROM [Legacy] +|F2: Previous Values | - | Onboard LAN2 Option ROM [Disabled] +|F3: Optimized Defaults | - | Onboard Video Option ROM [Legacy] v|F4: Save & Exit | - |> Network Stack Configuration | | -``` - -### ACPI Settings - -``` - | ACPI Settings |Enable or Disable Non | - | |uniform Memory Access | - | NUMA [Enabled] |(NUMA). | - | WHEA Support [Enabled] | | - | High Precision Event Timer [Enabled] | | -``` - -## Linux cmdline - -``` -$ cat /proc/cmdline -BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic root=UUID=2d6f4d44-76b1-4343-bc73-c066a3e95b32 ro audit=0 default_hugepagesz=2M hugepagesz=1G hugepages=32 hugepagesz=2M hugepages=32768 hpet=disable intel_idle.max_cstate=1 intel_iommu=on intel_pstate=disable iommu=pt isolcpus=1-23,25-47,49-71,73-95 mce=off nmi_watchdog=0 nohz_full=1-23,25-47,49-71,73-95 nosoftlockup numa_balancing=disable processor.max_cstate=1 rcu_nocbs=1-23,25-47,49-71,73-95 tsc=reliable console=ttyS0,115200n8 quiet -``` - -## Xeon Clx Server Firmware Inventory - -``` -Host. IPMI IP. BMC. BIOS. CPLD. CPU Microcode. PCI Bus. X710 Firmware. XXV710 Firmware. i40e. CX-5 Firmware. mlx5_core E810 Firmware. ice. -s33-t27-sut1. 10.30.55.18. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 9.20. 9.20. 2.22.20. 16.35.2000. 23.07-0.5.0. 4.30. 1.12.6. -s34-t27-tg1. 10.30.55.19. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 8.30. 8.30. 2.19.3. 16.32.1010. 5.9-0.5.5. N/A. N/A. -s35-t28-sut1. 10.30.55.20. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 9.20. 9.20. 2.22.20. 16.35.2000. 23.07-0.5.0. 4.30. 1.12.6. -s36-t28-tg1. 10.30.55.21. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 8.30. 8.30. 2.19.3. 16.32.1010. 5.9-0.5.5. N/A. N/A. -s37-t29-sut1. 10.30.55.22. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 9.20. 9.20. 2.22.20. 16.35.2000. 23.07-0.5.0. 4.30. 1.12.6. -s38-t29-tg1. 10.30.55.23. 1.67. 3.2. 03.B1.05. 0500002C. A5.01.18. 8.30. 8.30. 2.19.3. 16.32.1010. 5.9-0.5.5. N/A. N/A. -``` diff --git a/docs/content/overview/csit/test_tags.md b/docs/content/overview/csit/test_tags.md index de38945c17..23e09f925e 100644 --- a/docs/content/overview/csit/test_tags.md +++ b/docs/content/overview/csit/test_tags.md @@ -774,23 +774,43 @@ For traffic between DUTs, or for "secondary" traffic, see ${overhead} value. **AES** - IPSec using AES algorithms. + IPSec using AES encrytion algorithms. **AES_128_CBC** IPSec using AES 128 CBC algorithms. +**AES_128_CTR** + + IPSec using AES 128 CTR algorithms. + **AES_128_GCM** IPSec using AES 128 GCM algorithms. +**AES_128_NULL_GMAC** + + IPSec using AES 128 NULL GMAC algorithms. + +**AES_256_CBC** + + IPSec using AES 256 CBC algorithms. + **AES_256_GCM** IPSec using AES 256 GCM algorithms. +**AES_256_NULL_GMAC** + + IPSec using AES 256 NULL GMAC algorithms. + **HMAC** - IPSec using HMAC integrity algorithms. + IPSec using HMAC integrity/authorization algorithms. + +**HMAC_SHA_96** + + IPSec using HMAC SHA 96 integrity algorithms. **HMAC_SHA_256** @@ -800,6 +820,14 @@ For traffic between DUTs, or for "secondary" traffic, see ${overhead} value. IPSec using HMAC SHA 512 integrity algorithms. +**UDP_ENCAP** + + Encapsulate IPsec traffic in UDP. + +**ANTI_REPLAY** + + Enable IPsec Anti-Replay functionality. + **SCHEDULER** IPSec using crypto sw scheduler engine. diff --git a/docs/content/release_notes/current/_index.md b/docs/content/release_notes/current/_index.md index 6e1512d0ee..893a9c5416 100644 --- a/docs/content/release_notes/current/_index.md +++ b/docs/content/release_notes/current/_index.md @@ -1,118 +1,118 @@ --- bookCollapseSection: true bookFlatSection: false -title: "CSIT rls2402" +title: "CSIT rls2406" weight: 1 --- -# CSIT-2402 Release Report +# CSIT-2406 Release Report -This section will include release notes for FD.io CSIT-2402. The CSIT report -will be published on **Mar-13 2024**. The release plan is published on -[CSIT wiki](https://wiki.fd.io/view/CSIT/csit2402_plan) pages. +This section includes release notes for FD.io CSIT-2406. The CSIT report +has been published on **Jul-10 2024**. The release plan is published on +[CSIT wiki](https://wiki.fd.io/view/CSIT/csit2406_plan) pages. The release notes of the previous CSIT release can be found -[here]({{< relref "../previous/csit_rls2310" >}}). +[here]({{< relref "../previous/csit_rls2402" >}}). -## CSIT-2402 Release Notes +## CSIT-2406 Release Notes - [VPP Performance]({{< relref "vpp_performance" >}}) - [DPDK Performance]({{< relref "dpdk_performance" >}}) - [TRex Performance]({{< relref "trex_performance" >}}) - [VPP Device]({{< relref "vpp_device" >}}) -## CSIT-2402 Release Data +## CSIT-2406 Release Data -To access CSIT-2402 Release data please use following web resources: +To access CSIT-2406 Release data please use following web resources: - [CSIT Per Release Performance](https://csit.fd.io/report/) - - `CSIT Release` > `rls2402` + - `CSIT Release` > `rls2406` - `DUT` > `vpp` - - `DUT Version` > `24.02-release` + - `DUT Version` > `24.06-release` - `Infra` > `testbed-nic-driver of choice` - `Area` > `IPv4 Routing` `IPv4 Tunnels` `IPv6 Routing` `Hoststack` ... - - `Test` > `test of chioce` + - `Test` > `test of choice` - `Frame Size` > `64B` `78B` - `Number of Cores` > `1C` `2C` `4C` - `Test Type` > `MRR` `NDR` `PDR` - [CSIT Per Release Comparisons](https://csit.fd.io/comparisons/) for VPP - v24.02 vs v23.10 + v24.06 vs v24.02 - `REFERENCE VALUE` - `DUT` > `vpp` - - `CSIT and DUT version` > `rls2402-23.10-release` + - `CSIT and DUT version` > `rls2402-24.02-release` - `Infra` > `testbed-nic-driver of choice` - `Frame Size` > `64B` `78B` - `Number of Cores` > `1C` `2C` `4C` - `Measurement` > `Latency` `MRR` `NDR` `PDR` - `COMPARED VALUE` - `Parameter` > `Release and Version` - - `Value` > `rls2402-24.02-release` + - `Value` > `rls2406-24.06-release` - [CSIT Per Release Coverage Data](https://csit.fd.io/coverage/) - - `CSIT Release` > `rls2402` + - `CSIT Release` > `rls2406` - [CSIT Search Tests](https://csit.fd.io/search/) - `Data Type` > `iterative` - `DUT` > `vpp` - - `Release` > `rls2402` + - `Release` > `rls2406` - `Type a Regular Expression` > `2n-zn2 -1c ethip4-ip4base-[mrr|ndrpdr]` ".*" can be replaced by " " (white space). - `Choose a cell in the table` > A corresponding graph(s) is displayed. - `Click a datapoint in the graph` > Detailed information is displayed. -## CSIT-2402 Selected Performance Tests +## CSIT-2406 Selected Performance Tests -CSIT-2310 VPP v24.02 Performance Tests: +CSIT-2406 VPP v24.06 Performance Tests: - ip4 - - [2n-icx 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsrUO4cGjJfyDjbGlEmpq1G1G-HreqtIkAqUgtvfjgl2asHe9oJIe4YXoO1D0W5aKoFgVWbZOmYja_TQt3AY1CGLwHNHdpx9SRDQTYQ-s-QCv1Sug1PWjl3sEOS2i9gXvzAtoBxdX-lEZwtiNUb8B9A33D-xL4dCzxrZ6gzTYKmlRMkIFYwIk8ofnVbsT5TbTwLZOVC0m5QJHCSMzPbxP2ku2aQvtJciV1RXCXGi-QdtM6cedH6LFhVX1g_JNLPrv0N5f85VzCnKXTXcJrZQlzls7l0gWzZHKWTnfJXCtLJmfpXC5Jlsr6pt_w-vDXK-sv2WmuRg) - - [2n-spr 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_BrnUrZIWznupYem_o-iypvG1HHUlWpIv75KCKxNUkghaS466MWM2NEOAwpxw_QaqHsqykVRLQqs2iZNxcPzXVq4C2gUwuA9oLlPO6aObCDAHoJn0Eq9E3pNj1q5T7DDElpvYG7eQDuguNqd0gjOdoTqA7hvoG94VwJfDiWO6gnafEVBk4oJMhALOJEnNL_ajji_iRa-ZbJyISkXKFIYiTn9NmEv2a4ptN8kV1JXBHep8QJpN60Tt36EHhpW1XvGP7nks0t_c8lfzyXMWTrfJbxVljBn6VIuXTFLJmfpfJfMrbJkcpYu5ZJkqaxn_YbX-79eWf8ADdavEg) - - [2n-spr 100ge e810cq dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEX24hAuHFryD2TshUZN08U2lcrrcatKmwg4RGrpxYc4tmZXM97RSI5pG-glUv9U1cuqWVbYdD4v1f3iNv9CH9EohB0zoLnLu0A92UiAA0QOoJV6J2RNj1q5D_Ds19CxgQfzCtoBpdXhlL_obE-o1hAGD4MPBw58PnH8IBTUfyZBs4wJsqMg4ESflPFqP6r5U7U02EBWOrJ0gRLFkZrfLyfVb8FuKHZfJC15LIK7PHqBtJvypD2P0NPEmvZY8V8-cfFppk98QZ-w5GmGT3i1PGHJ09l8umSeTMnTDJ_M1fJkSp7O5pPkqW5vhm3YHN99dfsNi3az2g) - - [2n-spr 200ge cx7 mlx5 ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UjbYG7k-9dDU_xEUeZuYyo5YqSbp11cJgbVpezDkcdHBssTsMqMdBuTDnmntyb5m5SqrVhlWbROXbPn2HH9sPaocYXAOUC3ijsmS9gTYg3cMmOdbQleYQzWQDtDZQwmtU_CiNlAYoLA7neLnjbaE-Sdw30Df8IkE3y8kvxgFbb6CoFHHBBmIBZwIlDK3O45q_pctHZpJS0vULlAgP5Lz9-2k-oN1R779JmmJcxHcxOELVJgpTzi6EXoZWVWfK-7mlEtOzXXK3dIpTJma4xQ-LlOYMnU9p26aKZUyNccp9bhMqZSp6zklmSrrp37P3fkNWNY_glq9yg) - - [2n-c6in 200ge c6in.4xl ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91qwzAMhZ8muxkasZo0u9nFurzH8GxtDU1dYaeF7unnhIISuo0V2rUXvsgf5wQp-jiIhG7j6TVQ-5SVi6xaZFg1Np6y2fN9vPg2YJEj7JgBi4d456klHQjQgZk3DjDPP0ixIqfBsl1BwwWoUj2-gTJA3bJ_jkcwuiXMV-CdBWd9XwNfDjWOCopqt52osY2JsiMv4qQ_sfFyP_L80LXYtSct_ti4SB2FUS_ff5q4371eU2g-SV4ZxiIOE0c_Es20UrfnkXqYWFUPjv_ixInTiZz4gpww5ekETni1PGHK09k4XSZP8yJtpyNKcSi3tJt-Z8SJ0Q3spZ5R2kp_Z4RXylHaSOdiJDkq6zu38evhv6msvwDzBpLJ) - - [2n-c7gn 100ge c7gn ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91qwzAMhZ8muxkasZosu9nFurzH8GytDU1dYaeF7unnhIISuo0V2rUXvsgf5wQp-jiIhG7j6S1Q-5yV86yaZ1g1Np6y2ct9vPg2YJEj7JgBi4d456klHQjQgakWDlSeL0ixIqfBsl1BwwWoUj29gzJA3bJ_jkcwuiXMV-CdBWd9XwNfDzWOCopqt52osY2JsiMv4qQ_sfFyP_L80LXYtSct_ti4SB2FUS_ff5q4P7xeU2g-SV4ZxiIOE0c_Es20UrfnkXqYWFUPjv_ixInTiZz4gpww5ekETni1PGHK09k4XSZPj0XaTkeU4lBuaTf9zogToxvYSz2jtJX-zgivlKO0kc7FSHJU1ndu49fDf1NZfwEWdpKp) + - [2n-icx 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsrdNw4UCb_0DG2dKINDVrE1G-HreqtIkAqUgtvfjgl2asHe9oJIe4ZXoK1D0U5aKoFgVWbZOmYvZ4mxbuAho1h8F7QHOXdkwd2UCAPbTuA7RSL4Re071W7g3ssILWG5ibZ9AOKK73pzSCsx2hegXuG-gb3pfA5bHEt3qCNu9R0KRiggzEAk7kCc2vdyPOb6KFb5msXEjKBYoURmJ-fpuwV2w3FNpPkiupK4K71HiBtJvWiTs_Qo8Nq-oD459c8tmlv7nkL-cS5iyd7hJeK0uYs3Quly6YJZOzdLpL5lpZMjlL53JJslTWN_2WN4e_Xll_AeM_rqY) + - [2n-spr 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UrZIGznupYek_o-iypvG1HHUlWJIv75KCKxNW0ghaS466MWM2NEOAwpxy_QSqHsqymVRLQus2iZNxWxxnxbuAho1h8F7QPOQdkwd2UCAPQTPoJV6I_SaHrVyH2CHFbTewNy8gnZAcX04pRGc7QjVO3DfQN_woQQ-n0p8qydos4uCJhUTZCAWcCJPaH69H3F-Ey18y2TlQlIuUKQwEvPz24S9Yruh0H6SXEldEdylxguk3bRO3PsRempYVR8Z_-SSzy79zSV_PZcwZ-l8l_BWWcKcpUu5dMUsmZyl810yt8qSyVm6lEuSpbK-67e8Of71yvoLF6yvcg) + - [2n-spr 100ge e810cq dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEX24jRcOFDyD2TshUZNU7M2lcrrcatKmwg4RGrpxYc4tmZXM97RSI5py_QSqX-s6mXVLCtsOp-X6v7pNv-4j2jUAnYhAJq7vGPqyUYCHCAGBq3UO2HQ9KCV-wAf_Bq6YGBhXkE7oLQ6nPIXne0J1Rp48DB4PnDg84njB6Gg_jMJmmVMkB2xgBN9UhZW-1HNn6qlwTJZ6cjSBUoUR2p-v5xUv7HdUOy-SFryWAR3efQCaTflSfswQk8Ta9pjxX_5FIpPM30KF_QJS55m-IRXyxOWPJ3Np0vmyZQ8zfDJXC1PpuTpbD5Jnur2Ztjy5vjuq9tvl7y0Og) + - [2n-spr 200ge cx7 mlx5 ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVkFuwjAQfE24VIuSrUNOPRTyj8p1lhLVCdbajaCvr0FIm4j2EAnKxYc4tmZXM97RSPZhz_Tmyb5k5Tqr1hlWbROX7Pn1Kf7YelT5CgbnANUy7pgsaU-APXjHgHn-QegKc6gG0gE6eyihdQpW6h0KAxR2p1P8vNGWMP8E7hvoGz6R4OZCcsUoaPMVBI06JshALOBEoJS53XFU87ds6dBMWlqidoEC-ZGc328n1VvWHfn2m6QlzkVwE4cvUGGmPOHoRuhlZFV9rvg3p1xyaq5T7p5OYcrUHKfwcZnClKnbOXXXTKmUqTlOqcdlSqVM3c4pyVRZL_o9d-c3YFn_AJEQvio) + - [2n-c6in 200ge c6in.4xl ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91Kw0AQhZ8m3shIdsyPN15Y8x6y7o42NN0Ou7FQn95NKExCVSy0thd7kT_OCTOZj8OQ0G88vQTqHrNykdWLDOvWxlN2_3QbL74LWOQVbJkBi7t456kjHQjQgalaB5jn76RYkdNg2a6g5QJUqR5eQRmgfjk8xyMY3RHmK_DOgrN-qIHP-xoHBUW1H72osY2ZsiUv4qw_sfFyN_H80LXYtSct_ti4SD2FSS_ff5q437xeU2g_SV4ZxyIOE0c_Ec28Ur_jibqfWN2Mjv_ixInTkZz4jJww5ekITnixPGHK08k4nSdPVZG20wGlOJRr2k2_M-LE6Ar20sAobaW_M8IL5ShtpFMxkhyVzY3b-PX431Q2X3vik0k) + - [2n-c7gn 100ge c7gn ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91qwzAMhZ8muxkasZY0u9lFu7zH8GytDU1dYWeF7unnhIISuo0V2rUXvsgf5wQp-jiIhG7r6TVQ-5yVi6xaZFg1Np6yx_l9vPg2YJHPYMcMWDzEO08t6UCADky1dKDyfEmKFTkNlu0aGi5AlerpDZQB6lb9czyC0S1hvgbvLDjr-xr4cqhxVFBU-9GJGtuYKDvyIk76Exuv9iPPD12LXXvS4o-Ni9RRGPXy_aeJ-93rDYXmk-SVYSziMHH0I9FMK3V7HqmHiVX14PgvTpw4nciJL8gJU55O4IRXyxOmPJ2N02XyNCvSdjqiFIdyS7vpd0acGN3AXuoZpa30d0Z4pRyljXQuRpKjsr5zW78Z_pvK-gufQ5Mp) - ip6 - - [2n-icx 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsrUN64UCb_0DG2dKINDVrE1G-HreqtIkAqUgtvfjgl2asHe9oJIe4ZXoK1D0U5aKoFgVWbZOmYvZ4mxbuAhqFMHgPaO7SjqkjGwiwh9Z9gFbqhdBrmmvl3sAOK2j9PVTzZ9AOKK73pzSCsx2hegXuG-gb3pfA5bHEt3qCNu9R0KRiggzEAk7kCc2vdyPOb6KFb5msXEjKBYoURmJ-fpuwV2w3FNpPkiupK4K71HiBtJvWiTs_Qo8Nq-oD459c8tmlv7nkL-cS5iyd7hJeK0uYs3Quly6YJZOzdLpL5lpZMjlL53JJslTWN_2WN4e_Xll_AXFKrso) - - [2n-spr 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UrZIG7nOpYek_o-iypvG1HHUlWJIv75KCKxNW0ghaS466MWM2NEOAwpxy_QSqHsqymVRLQus2iZNxWxxnxbuAhqFMHgPaB7SjqkjGwiwh-AZtFJvhF7TXCv3AXZYQesfoZq_gnZAcX04pRGc7QjVO3DfQN_woQQ-n0p8qydos4uCJhUTZCAWcCJPaH69H3F-Ey18y2TlQlIuUKQwEvPz24S9Yruh0H6SXEldEdylxguk3bRO3PsRempYVR8Z_-SSzy79zSV_PZcwZ-l8l_BWWcKcpUu5dMUsmZyl810yt8qSyVm6lEuSpbK-67e8Of71yvoLpaivlg) - - [2n-spr 100ge e810cq dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEX24pBeOFDyD2TshUZN08U2lcrrcatKmwg4RGrpxYc4tmZXM97RSI5pG-glUv9Y1cuqWVbYdD4v1f3Tbf6FPqJRCDtmQHOXd4F6spEAB4gcQCv1TsiaFlq5D_Ds19DxAzSLV9AOKK0Op_xFZ3tCtYYweBh8OHDg84njB6Gg_jMJmmVMkB0FASf6pIxX-1HNn6qlwQay0pGlC5QojtT8fjmpfgt2Q7H7ImnJYxHc5dELpN2UJ-15hJ4m1rTHiv_yiYtPM33iC_qEJU8zfMKr5QlLns7m0yXzZEqeZvhkrpYnU_J0Np8kT3V7M2zD5vjuq9tvJi20Xg) - - [2n-spr 200ge cx7 mlx5 ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEXJ4mAuHFryD2SchUY4qbU2UcvrcatKmwg4RGrpxYc4tmZXM97RSA5xy_QSyD0V9brQ6wJ116aluF_dph-7gKpEGL0HVHdpx-TIBAIcIHgGLMt3Ql_ZnR7JROjdrobOP4B-fIXKAsXN4ZS-YI0jLD-AhxaGlg8k-Hwi-cEoaPsZBU06ZshILOBMoJT5zX5S87ds6TBMRlqSdoEihYmc328n1W9segrdF0lLmovgNg1foMrOeeLeT9DTyHRzrPg3p3x2aqlT_pJOYc7UEqfwepnCnKnzOXXRTKmcqSVOqetlSuVMnc8pyVTd3Axb7o9vwLr5Bh_nvk4) - - [2n-c6in 200ge c6in.4xl ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_Br3UrZY2zjqpYem_o-iSNvGxFGEpAbSr49iAmuTBBqwmx508IsZs-MdhsEhbj19BGpfi2pRyEWBsjHpVDy_PaaLbwPOSoSdc4Czp3TnqSUVCNCCnjcWsCy_SDhBVoFxZg2Nm4OoxMsShAaKq-NzOoJWLWG5Bm8NWOOPM_D9NONsIKPmOzKaZAyQHXkGB_qY5lb7HueKaqYrT4r5SThDkUJPy-VPY_anVxsKzQ_xK91amKHT6nugHk6Ke9dDTxuTdcf4K59c9ulGn9yEPmHO0w0-4d3yhDlPo_k0TZ5kbqdzl-T_6iaZm2lEj6bLUW6l33uEd8pRbqSxPOIcVfWD3fpN999U1Qf7j5NR) - - [2n-c7gn 200ge c7gn ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_BrnUjZY27jqpYem_o-gStvExFGEpAaSr69iAmuTFhqwmx508IsZs-MdhsEh7j2tArUvRbUs5LJA2Zh0Kh5fH9LFtwEXJcLBOcDFPN15akkFArSg5dqCKMs1CSfIKjDObKFxTyAq8fwOQgPFzfk5HUGrlrDcgrcGrPHnGfh2mXE1kFHzGRlNMgbIgTyDA31Mc5tjj_ODaqYrT4r5SThDkUJPy_efxuwPr3YUmhPxK91amKHT6nugHk6KR9dDLxuTdcf4K59c9ulGn9yEPmHO0w0-4d3yhDlPo_k0TZ5kbqdrl-T_6iaZm2lEj6bLUW6l33uEd8pRbqSxPOIcVfXM7v2u-2-q6i8e_5Mx) + - [2n-icx 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsxWl64dCS_0DG2dKINDVrE1G-HreqtIkAqUgtvfjgl2asHe9oJIe4ZXoK1D0U5bKolgVWbZOm4n5xmxbuAho1g8F7QHOXdkwd2UCAPbTuA7RSL4Re01wr9wZ2WEHrZ1DNn0E7oLjen9IIznaE6hW4b6BveF8CH48lvtUTtHmPgiYVE2QgFnAiT2h-vRtxfhMtfMtk5UJSLlCkMBLz89uEvWK7odB-klxJXRHcpcYLpN20Ttz5EXpsWFUfGP_kks8u_c0lfzmXMGfpdJfwWlnCnKVzuXTBLJmcpdNdMtfKkslZOpdLkqWyvum3vDn89cr6C3sgryo) + - [2n-spr 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UrZIGznOpYcm_o-iypvG1HHUlWpIv75KCKxNW0ghaS466MWM2NEOAwpxx_QcqHssymVRLQus2iZNxezpPi3cBTRqDoP3gOYh7Zg6soEAewieQSv1Sug1LbRy72CHNbR-DtXiBbQDipvDKY3gbEeo3oD7BvqGDyVwdSrxrZ6gzUcUNKmYIAOxgBN5QvOb_Yjzm2jhWyYrF5JygSKFkZif3ybsNdsthfaT5ErqiuAuNV4g7aZ14t6P0FPDqvrI-CeXfHbpby7567mEOUvnu4S3yhLmLF3KpStmyeQsne-SuVWWTM7SpVySLJX1Xb_j7fGvV9Zfr36v9g) + - [2n-spr 100ge e810cq dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFuwjAQfE16qbayjUO49ADNPyrX3paIELZrg0RfX4OQNlHbQyQolxzi2JpdzXhHIzmmHeNrxPa5KFdFtSpM1YS8FLPlY_5xG41VczgQgbFPecfYoosIpoNIDFqpDzSkcaGV_4RAYQMNzaFavIH2gGl9OuUveteiURvgLkAX-MRhXi4cPwgFDfskaJYxQA7IAg70SRmtj72aP1VLg2N00pGlC5Qw9tT8fjmpfme3xdh8obTksQju8-gF0n7Ik47UQy8Tq-pzxX_5RJNPI32iG_pkpjyN8MncLU9mytPVfLplnuyUpxE-2bvlyU55uppPkqeyfuh2vD2_-8r6GzJztL4) + - [2n-spr 200ge cx7 mlx5 ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEXJ4tRcOFDyD2SchUY4qbU2UcvrcatKmwg4RGrpxYc4tmZXM97RSA5xy_QSyD0W9brQ6wJ116aluH-6TT92AVW5gtF7QHWXdkyOTCDAAYJnwLJ8J_SV3emRTITe7Wro_Ar0wytUFihuDqf0BWscYfkBPLQwtHwgwecTyQ9GQdvPKGjSMUNGYgFnAqXMb_aTmr9lS4dhMtKStAsUKUzk_H47qX5j01Povkha0lwEt2n4AlV2zhP3foKeRqabY8W_OeWzU0ud8pd0CnOmljiF18sU5kydz6mLZkrlTC1xSl0vUypn6nxOSabq5mbYcn98A9bNNy6dvq4) + - [2n-c6in 200ge c6in.4xl ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_Br3UrZY29jKpYem_o-iStvGxFGEpAbSr69iAmuTFhqwmxx08IsZs-MdhsEh7jy9BuqeimpVyFWBsjXpVDw-36eL7wIuyhr2zgEuHtKdp45UIEALum4tYFl-kHCCrALjzAZaV4OoxPINhAaK6-NzOoJWHWG5AW8NWOOPM_DlNONsIKPmMzKaZIyQPXkGR_qY5taHAecX1UxXnhTzk3CGIoWBlp8_jdnvXm0ptF_Er_RrYYZOqx-AejwpHtwAPW1MNj3jv3xy2acLfXIz-oQ5Txf4hFfLE-Y8TebTPHmSuZ3OXZK31U0yN9OEHs2Xo9xKf_cIr5Sj3EhTecQ5qpo7u_Pb_r-par4BhGuT0Q) + - [2n-c7gn 200ge c7gn ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_Br3UrZYmzjqpYek_o-gStvExFGEpAbSr69iAmuTFhqwmx508IsZs-MdhsEhHjytA7UvRbUq5KpA2Zh0KmbLx3TxbcB5uYCjc4Dzp3TnqSUVCNCClhsLoiw3JJwgq8A4s4PGLUBU4vkNhAaK2_NzOoJWLWG5A28NWOPPM_D1MuNqIKPmIzKaZAyQI3kGB_qY5ranHucH1UxXnhTzk3CGIoWelu8_jdnvXu0pNJ_Er3RrYYZOq--BejgpnlwPvWxM1h3jr3xy2acbfXIT-oQ5Tzf4hHfLE-Y8jebTNHmSuZ2uXZL_q5tkbqYRPZouR7mVfu8R3ilHuZHG8ohzVNUP9uD33X9TVX8Bp8yTsQ) - ipsec - - [3n-icx 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYwlK7Fw-ufQ_D0tldkv4gYN369NK6CW2MiZql9cClP5kBBr58yQRjW43PBquHJNsl-S6huSzdI9k83rqXrgxlKYVOKaDszn1prJAbhE0DUpyBpOkRqSK4Jal4Ad4dQOhe2RZIRrZ7IALQnqRiUhkULLVNZd7A_e-HSWRjgaOh2f1R1NCUeliZPl1W_lKGj5av1kddcbNIh9oHZ1X7NHXqfc63e_H5XCP3Az636KMWzaSen27Yjz9oXqOR7-gnGY_PZwiHaRIU87VtrybRyznmxZixLlMVmV6FqQrMlEZPAzClq3pKo6eLMw3tKYueBmDKVvWURU8XZxrOU1nLc2x7_4p0OL3_1vX-mmiU9CpEAzsaW94AROmajsaGd3GigR2N7W4AomxNR2OzuzhR72hW3DStrse73qz4ALThK64) - - [3n-icx 100ge cx6 dpdk 40tnlsw](https://csit.fd.io/report/#eNrtmEtOwzAQQE8TNmhQ7DqkGxaU3AOlztBa5GNsUxpOjxMqTSqEBKhOWHiTj2Zsj_30pJGt6ww-WqzvkmyT5JuE56ryj2R1f-1fprZcpBwOWgMXN_7LYI2lRVi1oOQRWJrukGuGa5bKF6h09QzS9Np1wDK23gKTgG6vtFDaohSpa2v7Bv5_O8yiWgclWp7d7mQDbWWGpfnDaekvdVC0enUU9dWdRQ5oKHhWNqXpfU8532-GBpQGSxrxuUeKOrSTgn66Yxr_ZMoGrXpHmmQ8P8qQHtQkKM_Xdr2eRE8HmRdjxsJUdaR6Gao6NFUeXQ1BlS_rKo-uzk81uKsiuhqCqljWVRFdnZ9qQFdVo46xBf4z1OH4_l0H_GumUdTLMA3taWx_QzDli3oam9_5mYb2NLa-IZiKRT2Nje_8TMnTrLhqO9OMd8BZ8QHg7TU-) - - [3n-spr 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYwlK7Fw-79j0MpbO7JP1BwGp9emndhG2MiZql9cClP5kBBr58yQRjO41PBuuHJNsn-T6huazcI9nsbt1L14aylEKvFFB257401sgNwqYtwSgNJE2PSBXBLUnFM_D-AEIPynZAMrItgQhAe5KKSWVQsNS2tXkF91-Os8jWAkdDs_ujaKCt9Lg0fTwv_aUOH61erI-66maRHrUPzsr2aeo0-JzvN-MHcI3cj_jco49aNBcF_XTHfvxB8waNfEc_yXR-PkM4UBdBMV_bDuoiej7IvJgyVqaqItXrUFWhqdLoagiqdF1XaXR1earBXWXR1RBU2bqusujq8lQDuiob-RZb4D9DHY_v33XAv2YaRb0O09CexvY3BFO6qqex-V2eaWhPY-sbgilb1dPY-C7P1HuaFTdtp5vpDjgrPgDqXTZ2) - - [3n-spr 200ge cx7 mlx5 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYlgXrxYNr38OwdNwl6Q8BrK1PL62b0MbEaFzEA5f-ZAYY-PIlE4ztNT4ZbO4zts_KfUZKWbtHtnu4di_dGEJzAoNSQOiN-9LYIDcIu46DURpInh-RqEKM5YDcQtuMDISelO2hYMXdAQoBaE9SUakMCprbrjGv4P4P8zyys8DREHZ7FC10tZ4XJ4_nxT9V4qP1i_VRV98mMqD2wU3hPk2dJp_z1Xb8EK6R-zEfu_RRi2ZV0nf37Mc_a96ikW_oJ1lO0GcIB2sVFNu17aRW0fNRltWSEZ2sSmQvRVaFJ0uSs2HIktjOkuRsDLJ_4CxNzoYhS2M7S5OzMcgGdVa2ckyt8S_Azgf4DzvjH3NNwl6Ka3hfU1schiuJ7GtqimNwDe9raonDcKWRfU0NcQyu3ldWXXW9bpc7Y1a9A6ljU84) + - [3n-icx 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmEtuwyAQQE_jbqqpDMFxNl0k9T0qgicJkj8UqBv39MVuJGJVldoq2F2w8UczwMDTk0YY22p8Nlg9JtkuyXcJzWXpHslqe-9eujKUpWvolALKHtyXxgq5QVg1IMUZSJoekSqCG5KKF-DdAYTulW2BZGSzByIA7UkqJpVBwVLbVOYN3P9-mEQ2Fjgamq2Pooam1MPK9Omy8pcyfLR8tT7qiptEOtQ-OKnap6lT73O-3YvP5xq5H_C5RR-1aK7q-emG_fiD5jUa-Y5-kvH4fIZwmK6CYrq27dVV9HKOeTFmLMtURaY3YaoCM6XR0wBM6aKe0ujp7ExDe8qipwGYskU9ZdHT2ZmG81TW8hzb3r8iHU7vv3W9vyYaJb0J0cCOxpY3AFG6pKOx4Z2daGBHY7sbgChb0tHY7M5O1DuaFXdNq-vxrjcrPgBPCCxu) + - [3n-icx 100ge cx6 dpdk 40tnlsw](https://csit.fd.io/report/#eNrtmEtOwzAQQE8TNmhQ4jpNNywouQdKnaG1yMfYpjScHidUmkQICVCddOFNPpqxPfbTk0Y2ttX4ZLC6j9JtlG0jlsnSPaLVw6176cowHq_hqBQwfue-NFZYGIRVA1KcIInjPTKV4CaJxSuUqnwBoTtlW0jSZLODRADag1RcKoOCx7apzDu4_10_i2wsFGhYut6LGppS90uzx_PS3-qgaPlmKeqqm0SOqCk4KZvS1KGjnJ83QwMKjQWN-NojRS2aUUG_3TGNf9ZFjUZ-IE0ynB9lCAdqFBTTtW2nRtHzQWb5kLEwVRWoXoaq8k2VBVd9UGXLusqCq_NT9e4qD676oMqXdZUHV-en6tFVWctTaIH_DbU_vqvrgP_MNIh6Gaa-PQ3trw-mbFFPQ_M7P1PfnobW1wdTvqinofGdnyl5muY3Tavr4Q44zT8BhHQ1_g) + - [3n-spr 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYwtLdvXhw7XsYSmd3SfqDgNX69NK6CW2MiZql9cClP5kBBr58yQRjW41PBqv7JDsku0NCd7J0j2TzcOteujKUpVvolALK7tyXxgq5Qdg0BRilgaTpCakiuCepeAbeHUHoXtkWSEb2BRABaM9SMakMCpbapjKv4P6LYRbZWOBoaLY9iRqaUg9L08fL0l_q8NHyxfqoq24W6VD74Kxsn6bOvc_5fjN-ANfI_YjPPfqoRTMp6Kc79uOPmtdo5Dv6Scbz8xnCgZoExXxt26tJ9HKQu3zMWJmqilSvQ1WFpkqjqyGo0nVdpdHV5akGd5VFV0NQZeu6yqKry1MN6Kqs5Vtsgf8MdTi-f9cB_5ppFPU6TEN7GtvfEEzpqp7G5nd5pqE9ja1vCKZsVU9j47s8U-9plt80ra7HO-As_wCN5Dc2) + - [3n-spr 200ge cx7 mlx5 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYloWtFw-79j0MS8ddkv4QwNr69NK6Cd2YGI2LeODSn8wAA1--ZIKxvcYng81DxvZZuc9IKWv3yDa7W_fSjSE038KgFBB65740NsgNwqbjYJQGkudHJKoQYzkgt9A2IwOhJ2V7KFhxf4BCANqTVFQqg4LmtmvMK7j_wzyP7CxwNIRtj6KFrtbz4uTxvPinSny0frE-6uq7iAyoffCicJ-mTpPP-Wo7fgjXyP2Yj136qEWzKum7e_bjnzVv0cg39JMsJ-gzhIO1CorLte2kVtHzUZbVkhGdrEpkr0VWhSdLkrNhyJLYzpLkbAyyf-AsTc6GIUtjO0uTszHIBnVWtnJMrfEvwM4H-A874x9zTcJei2t4X1NbHIYriexraopjcA3va2qJw3ClkX1NDXEMrt5XVt10vW6XO2NWvQNfqlSO) - hoststack quic - - [3n-icx 100ge e810cq dpdk ip4udpquic](https://csit.fd.io/report/#eNrlVctuwyAQ_Br3Um0FxJZz6aGJ_6PCsK1RSExYHDX9-hIr6tpqc80hvgDSzOxrtIJSH_Gd0L8W1aaoN4Wqnc1HsXp7zlf0pEqh4BQCqPIlvyJ61ISwOoAzXyCF-EQVJK6lMEewwe6g6ylR0mYHUq1FC9IApg5cKAcbjoMz7SVADomm66ENdMmnttd8f5IzaofEaNbPkBNGBme1Mi10Z-bc7oAFOqJmxW9jTEhIk5put8mKj6j3SO4bWTaOiRkmWzIBzTxbOocJep1e3YyMO_lHRnvMfC8FLcDH_9p9UD-XZecju7ms5bzzblbN06GP-_HPrJof9LcJqA) - - [3n-icx 100ge cx6 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCYte99NDU_6gw3taoOKYsjpy8PsSKurbaXHNwLoA0M8zujhAU-4AfhO41K7ZZuc1UaZu0ZJu3x7QFRyoXCvbeg8qf0imgQ00Imx1YM4IU4guVl2Z8bkbo3FhA21OkqM03SPUiapAGMLZgfT40_mewpj7r041o2h5qT2c79X6x--PNaDNERpN-gewxMLgolWm-PTDnagPM1wE1C377YkJEmpV0vUtWfAbdIdkjsmyaEjNMCmQGmqVbPPgZehleWU2M26RHRjuUwjgpaP0p_tftOtO8qzBXnOVdPcwbv8uietj1oZv-yqI6ATY_CZg) - - [3n-spr 200ge cx7 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVctugzAQ_Bp6qbayHRC99NCE_4iM2RRUExyvQUm-Pg6KsqA-jjmEi21pZvY1WplC53FLaD-SbJ3k60TlTRWPZPX5Gi9vSaVCweAcqPQtvjxa1ISw2msg50EJ8YXKSXPMB9QBWnvMoO4oUNDmG6R6FyVIAxhqaFzaV-7QN6a8hohB0dQdlI6uGdXmlvFHekarPjAa9TNkQM_grFqmufrEnP96YIn2qFlzb40JAWlS1d-NsmLndYvUnJFl46CYYaItE9DMs4WTm6C3-eXFyHiYh2S0RSmMlYIW4eVvDT-tp0uz9LkdXdqSPnhHs-Jl3_l2_EOz4gJZsRPY) + - [3n-icx 100ge e810cq dpdk ip4udpquic](https://csit.fd.io/report/#eNrlVctOwzAQ_JpwQYtsNyG9cKDkP5BjL8Sq27hep6J8PW5UsYmg1x6ai21pZvY1WplSH_Gd0L8U1aaoN4Wqnc1HsXp9zFf0pErxDMcQQJVP-RXRoyaE1R6c-QIpxCeqIHEthTmADXYLXU-JkjZbkGotWpAGMHXgQjnYcBicac8Bckg0XQ9toHM-9XbJ9yc5o3ZIjGb9DDliZHBWK9NCd2LO9Q5YoCNqVvw2xoSENKnpepus-Ih6h-S-kWXjmJhhsiUT0MyzpVOYoJfp1c3IuJF_ZLTHzPdS0AJ8_K_dO_VzWXbes5vLWs4b72bVPOz7uBv_zKr5Af0mCeg) + - [3n-icx 100ge cx6 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCYse99JDU_6gw3taoOKYsjpy-vsSKurbaXHNwLoA0M8zujhAU-4BvhO4lK_ZZuc9UaZu0ZJvdY9qCI5WLLRy9B5U_pVNAh5oQNgewZgQpxAcqL824bUbo3FhA21OkqM0nSPUsapAGMLZgfT40_muwpj7r041o2h5qT2c79Xqx--PNaDNERpN-gRwxMLgolWm-PTHnagPM1wE1C377YkJEmpV0vUtWvAfdIdlvZNk0JWaYFMgMNEu3ePIz9DK8spoYt0mPjHYohXFS0PpT_K_bdaZ5V2GuOMu7epg3fpdF9XDoQzf9lUX1Az2OCdg) + - [3n-spr 200ge cx7 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVctugzAQ_Bp6qbayHQi99NCU_6iM2QZUE1yvQUm-Pg6KsqCmPeYQLralmdnXaGUKncdPQvuWZJsk3yQqb6p4JKv353h5SyoVaxicA5W-xJdHi5oQVjsN5DwoIbaonDT7fEAdoLX7DOqOAgVtvkGqV1GCNIChhsalfeV--saU5xAxKJq6g9LROaP6uGT8lZ7Rqg-MRv0MGdAzOKuWaa4-MOe_HliiPWrWXFtjQkCaVPV3o6z48rpFao7IsnFQzDDRlglo5tnCwU3Qy_zyYmTczUMy2qIUxkpBi_DyVsMP6-nSLH1sR5e2pHfe0ax42nW-Hf_QrDgBZGAUGA) - hoststack tcp udp - - [3n-icx 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbNe99JDU_4gwbGorJKYsiZK-vsSKuraqNKf2EF8AMTPsDiMExT7gitC9ZuUyq5aZqjqbhixfPKYpOFKFUHDwHlTxlFYBHWpCyHfQmSNIId5ReYkvUpgPsN5uoO0pUtRmA7J4Fg1IAxhb6HwRjW_OYmd9OqfXNm1iWOfQeDoXVW-Xoj86YNTuI6OprwlywMDgpGGm-fbEnOs2WKADalZ8u2NCRBr1dMMry9ZBb5G6T2TtcGHMMCmcEWimJePJj9DLFVb1wPiHJMloh9I4KWgugf5m-T5y3dv5vNBrXu8mybm90BuW_z7Xsn7Y9WE7_KVl_QUYjRDu) - - [3n-icx 100ge cx6 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVcFuwyAM_ZrsMnkCkjSnHdblPyYC7hKNNAjTKt3Xj0bVnGjqeuqluQDiPWM_P1lQHAJ-ELrXrNxm1TZTVWfTkuVvz2kLjlQhFBy9B1W8pFNAh5oQ8j10ZgQpxCcqL824sSP0biyhHShS1OYLZLERDUgDGFvofBGNb86xzvr0zKBtusSwy6HxdM6p3i85_xTAqD1ERlNZC-SIgcFFvUzz7Yk5V1UwXwfUHPArjgkRaVbSDakctgu6R-q-kWOnfjHDJGtmoFmmjCc_Qy8drOqJcX8fyWiH0jgpaCV2_qf4IVw92NVM5zWpj-LjyqbzhuL7u1rWT_sh9NMfWtY_O78Q3g) - - [3n-spr 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFOwzAQfE24oEW2kxAuHCj5B3LsLYmaNovXrVRejxtVbCJEe4JDc7Etz4x3xyPLHIeAb4z9c1ausmqVmarzacjyl_s0hZ5NoQwciMAUD2kVsEfLCPmuAaYAWql3NKTxSSv3AZ78BtqBI0frNqCLR9WAdoCxhY6K6Kg5qXtP6aDB-rSJYZ1DQ3yqal7PVX-0IKjfR0FTYzPkgEHAWcdCo_YonAs-RGEDWpF82xNCRJ40dcWsyNbBbpG7TxTteGPCcCmeCejmJeORJuj5Dqt6ZPxHluxsj9r1WvFiIr3k-UaS3fsFvdLfzN5Olot7pVc8_32yZX23G8J2_FPL-gse3xSG) - - [3n-spr 200ge cx7 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbNenHpr4HxWGTW0Vx4glVtLXl1hR11bV5NQe4gsgZobdYYSgOAR8I3QvWbnJqk2mqs6mIctfH9MUHKlCKBi9B1U8pVVAh5oQ8r0G8gGUEO-ovDTHakQdoXfHEtqBIkVtPkAWz6IBaQBjC50vovHNWe6sTycN2qZNDLscGk_nsmp7KfujB0btITKaOlsgIwYGFy0zzbcn5lwzwhIdULPm2x8TItKsqxtuWbYLukfqPpG105Uxw6SAZqBZlownP0Mvl1jVE-Nf0iSjHUrjpKD1hHrN9L1ke7Breqm_ub2jNNf3Um-Y_vtsy_phP4R--lvL-gsy1Rse) + - [3n-icx 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbMe99NDE_4gwbGorJKYsiZq-vsSKuraqNKf2EF8AMTPsDiMExT7gmtC9ZOUyq5aZqjqbhix_fUxTcKQKsYCj96CKp7QK6FATQr6HznyAFOINlZf4LIV5B-vtFtqeIkVttiCLhWhAGsDYQueLaHxzFjvr0zm9tmkTwyaHxtO5qFpdiv7ogFF7iIymvibIEQODk4aZ5tsTc67bYIEOqFnx7Y4JEWnU0w2vLNsEvUPqPpG1w4Uxw6RwRqCZlownP0IvV1jVA-MfkiSjHUrjpKC5BPqb5fvI9WDn80Kveb2bJOf2Qm9Y_vtcy_ph34fd8JeW9Rcj_BEu) + - [3n-icx 100ge cx6 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVU1vwyAM_TXZZfIUyNdph3X5HxMBd4lGGoRplfbXl0bVnGjqeuqluQDiPWM_P1lQGDx-Edr3pNgk1SaRVWfikmQfr3HzlmSelnBwDmT-Fk8eLSpCyHbQ6RFEmn6jdEKPpRmht2MB7UCBgtI_IPIybUBowNBC5_KgXXOJtcbFZwZl4iX6bQaNo0tO-XnN-acARs0-MBrLWiAH9Awu6mWaa4_MuamC-cqj4oBfcUwISLOS7kjlsK1XPVJ3Qo6d-sUMHa2ZgXqZMhzdDL12sKonxuN9JK0sCm1FSiux8z_FT-Hq3qxmOm9JfRYfVzaddxQ_3tWiftkNvp_-0KI-A0YOER4) + - [3n-spr 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVctuwyAQ_Br3Um0FfsS99JDU_1Fh2NRWSLxlSaT060usqGuranJqD8kFEDPD7jBCcBwCvjH6l6xaZfUqy-vepSErlo9pCp7zUi3gQAR5-ZRWAT0aRih2LTAF0Eq9Y04an7WyH-DIbaAbOHI0dgO6XKgWtAWMHfRURkvtSe0dpYMG49ImhnUBLfGpav56rvqjBUHdPgqaGpshBwwCzjoWGnVH4VzwIQoT0Ijk254QIvKkqStmRbYOZovcf6JoxxsThk3xTEA7LxmPNEHPd1g3I-M_smRrPGrrteK7ifSS5xtJdu_u6JX-ZvZ2sry7V3rF898nWzUPuyFsxz-1ar4AK24Uxg) + - [3n-spr 200ge cx7 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbMenHpr6HxWGTW0Vx4glVtLXl1hR11bV5NQe4gsgZobdYYSgOAR8I3TPWbnNqm2mqs6mIctfHtMUHKlCbGD0HlTxlFYBHWpCyPcayAdQQryj8tIcqxF1hN4dS2gHihS1-QBZbEQD0gDGFjpfROObs9xZn04atE2bGHY5NJ7OZdXrpeyPHhi1h8ho6myBjBgYXLTMNN-emHPNCEt0QM2ab39MiEizrm64Zdku6B6p-0TWTlfGDJMCmoFmWTKe_Ay9XGJVT4x_SZOMdiiNk4LWE-o10_eS7cGu6aX-5vaO0lzfS71h-u-zLeuH_RD66W8t6y9AhBte) - nat44 - - [2n-icx 100ge e810cq avf ethip4tcp tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZIsiT70kNS_0dQ5E1tcJytpJikX185DcimGAotLYRc9JpZ7Y6GRT4cHG48ds-ZWmfFOhNFW8chy1ePcXKdF5IJGIhAyKe4ctih8Qiih9aegDP2ioI4lpzZNzDDDlqS4_EWuAUMTdwGS-PpdoxrOBMSSOfgtVRcQKBjgL52Y1Lxck36pYKE1seQ0FjXDBnQJXBWcKJRc55wlmQkvnFoUkDUkaCAflLMN8Wm8J0ze_TtO6Y7xodLBBvNmWB2njmcaYJen7CoLox_c5LuTv7USfpzJ7VSuf5UJ7koC13edlsu6L2Zzlzyk-5-_mp_quqhP7j95e9U1QekIvTr) - - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZYa0n2pYek_o-iypva4DhbSTGkX185DcimGAotLYRc9JqRdmeHRT4cHD176h8ztc3KbYZl18QhKzb3cXK9R5kjjMyA8iGuHPVkPAEO4NmByPNXQhZUidy-gRl30LGcjl9AWKDQxm2wDIMJUlIDrchRAusCvJZKIAQ-BhgaNwXFp0vQLxkktDmGhMa8FshILoGLhBON29OMsyYj8Y0jky5EOQkK5GfJfFNsur5zZk--e6f0xlS4RLDRnBlml5HDiWfopYRlfWb8m5N8c_KnTvKfO6mVKvSnOimwKnV13W25ovdqOnPNT775-av9qeq74eD2579T1R-52PPT) - - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed cps](https://csit.fd.io/report/#eNrtVdtqwzAM_ZrsZWjYju3kZQ_r8h_Fc9QlkKaa7QXar5_XFZSwFQYbG5S--MKRfHR0EI5pF3AdcbgvzKqoVoWq-jYvRflwm7cwRKWFgokIlL7Lp4ADuoigRogUQArxjIok1lL4F3DTBnrSYPUTSA-YunxLnmB0SWtsoZNCaSBbQrTaSAWeIoxteKdUjyfKT_yMtq-J0VzVApkwMLgol8Oo289izongeBfQcUJWw1DCOCvme1o5exPcFmN_QH4id41xn41hSPolb9rTDD01sGqOEf_kIl1d_JmL9NcuWmNK-yFNS1VXtr7ocfxa7oVM5Bkv6erlL86laW7GXdge_0rTvAFXze5j) - - [2n-spr 200ge cx7 mlx5 ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVdtqwzAM_ZrsZWjYip30ZQ_t8h_Dc7QlkKTCdkPbr6_bFZwwAoMNCqUvvnAk6xwdhH3YOnr31L1mepOVmwzLto5Llq-f4-Y6j0ogjMyA6iWeHHVkPAEO4NkBCvFFyNLuy5FMgL7ba2hZgRTiA6QFCk28BsswmKAU1dBIgQq4yMEXSkuEwLsAQ-3OZfHtWvYHh4TWu5DQyGyGjOQSOKOcwrg5TGKWhaQM48iklCgoQYH8hM4v5ab0T2d68u2R0hvn1qUAGw2aYHZeORx4gl6bWFaXiBu6yQ83_-4m38DNQuu8-NanJK7KYnXv47mg-I4mdMlTfnj6z3Oqq6dh6_rLX6qrEyEm_aM) + - [2n-icx 100ge e810cq avf ethip4tcp tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZIsiT70kNS_0dQ5E1tcJytpJikX185DcimGAotLYRc9JpZ7Y6GRT4cHG48ds-ZWmfFOhNFW8chy1ePcXKdF5JpGIhAyKe4ctih8Qiih9aegDP2ioI4lpzZNzDDDlqS4_EWuAUMTdwGS-PpdoxrOBMSSOfgtVRcQKBjgL52Y1Lxck36pYKE1seQ0FjXDBnQJXBWcKJRc55wlmQkvnFoUkDUkaCAflLMN8Wm8J0ze_TtO6Y7xodLBBvNmWB2njmcaYJen7CoLox_c5LuTv7USfpzJ7VSuf5UJ7koC13edlsu6L2Zzlzyk-5-_mp_quqhP7j95e9U1QetMfUr) + - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZYsiT70kNS_0dR5U1tcJytpBjSr6-cBtamGAotLYRc9JqRdmeHRSEePD4H7B8zvc3KbSbLrklDVmzu0-T7IFVuYCQCqR7SymOPNiDIAQJ5EHn-ipIEViJ3b2DHHXSkpuMXEA4wtmkbHcFgo1LYQCtyqYBMAcEoLSREOkYYGj8FlU-XoF8yYLQ5RkZTXgtkRM_gImGmUXuacdZkMN96tHwhyWEoYpgl802xfH3n7R5D9478xlQ4Jrhkzgxzy8jxRDP0UsKyPjP-zUm6OflTJ-nPnTRaF-ZTnRKyKk113W25ovdqOnPNT7r5-av9qeu74eD3579T1x_C5_QT) + - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed cps](https://csit.fd.io/report/#eNrtVdtqwzAM_ZrsZWjYju3kZQ_r8h_Fc9QlkKaa7QXar5_XFZSwFQYbG5S--MKRfHR0EI5pF3AdcbgvzKqoVoWq-jYvRflwm7cwRKWFhYkIlL7Lp4ADuoigRogUQArxjIok1lL4F3DTBnrSYPUTSA-YunxLnmB0SWtsoZNCaSBbQrTaSAWeIoxteKdUjyfKT_yMtq-J0VzVApkwMLgol8Oo289izongeBfQcUJWw1DCOCvme1o5exPcFmN_QH4id41xn41hSPolb9rTDD01sGqOEf_kIl1d_JmL9NcuWmNK-yFNS1VXtr7ocfxa7oVM5Bkv6erlL86laW7GXdge_0rTvAFenO6j) + - [2n-spr 200ge cx7 mlx5 ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZIsh659JDU_1FUeVsbbGeRFJPk66OkAdkUQ6GFQMhFD2ZXO7PDohC3Ht8Ddq-F2hRmUwjT1mkpyvVz2nwXhGQaRiIQ8iWdPHZoA4IYIJAHwdgXCuJub0a0Efpur6AlCZyxD-AOMDbpGh3BYKOUWEPDmZBAuoSgpeICIu0iDLU_lxVv17I_OGS03sWMJmYzZESfwRnlHEbNYRKzLCRnWI82pyRBGYoYJnR-KTenf3rbY2iPmN84ty4HuGTQBHPzyvFAE_TaRFNdIm7oJj3c_LubdAM3tVKl_tYnuVgZvbr38VxQfEcTuuQpPTz95zlV1dOw9f3lL1XVCSx1_eM) - tunnels (gnv, vxlan, gtpu) - - [2n-icx 100ge e810cq avf ethip4udpgeneve](https://csit.fd.io/report/#eNrtVsGKwjAQ_ZruZZmlia3dyx7U_ofEdNRCjWOSFvXrN5XCtCvCHgSh9ZKEvDeZmTweifNHi2uH1U-ULqNsGcmsLMIQzRafYbKVk0ksoSECmXyFlcUKlUOQBkp9BhHHO5Qk8FvE-gSq2UJJydrXxmDlYJ5sQGhAvw-70M11QTs02CCIeSC2AZv2SFPYNrNcdZnvymC0qD2jobgB0qBlcFA102h_6XEe9cJ8ZVFxQK9Fpnh0vaL-1TIHb606oCuvyCeEu2NcB5kYEnqY1l-oh3b3mOU3xms1pbemT9GUXqvp9Gw6dpdOz6Qj96hMp_eYDnseo0__qEpvVZ_t1TT_MEd7uP1_0_wX2pkbKQ) - - [3n-icx 100ge cx6 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlkFuwjAQRU-TbqqpksEhqy4KuQcKzhQiOcayHQicvg5CmkQtCxCFjTdx5P_tGfvpS3Z-Z2nlSH0m-SIpFgkWTR0-yezrPQxWORQpwt4YQPER_iwpqhzBTEMje8jSdENoMtnP6x5a1efQGLHyndakHMzFGjIJ5LdhduNN5w6Dvh520LUdCuHyUuhXVVbrzrMaepkoe7IsTppkm9ke2XO1dfZXlipeMDoRWzy5UVN_nZC937ZqyTUn4gXhZliXAQJLmZxW8UczUi_XVpRnx1OJmUjsHmLm_4lhzNhtxPDVGcOYsUcSe0LGRMzYbcTEqzMmYsYeSYwzlpdvemfb85sxL38A-znb1g) - - [3n-spr 200ge cx7 mlx5 vxlan](https://csit.fd.io/report/#eNrtVcFuwjAM_ZpymTy1oV1PHAb9D5SmHlRKg-WEquzrF1glt0Jw4YCEuCRRnl_s5ycrPhwYtx7tKinWSblOVNk2cUmW3x9xY-tVniroiUDln_HEaFF7hKXT4IlBpekOFWVmKHvUATo7FNBSvg1H59B6-MpryAxg2MfbfrDagVV1U8dHOm0sO3ANnzOqzZjxKr2gzTEIGouaIT2ygLNqJYz2J4m5p0EomlELZyJNQgL6SV23pQrjh3WHvv1FocVGCW6iLQJlZp4rnGiCjv0rq0vEczykt4cPeUjP8XAwZ2EvPoH_Il9q9kbf6O3bw_NWVAt34O7y_xXVH06v_as) - - [3n-spr 200ge cx7 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlsFugzAMhp-GXSZP4IZx2mEt71Gl4LVIgVpJYO2efqGqZNCmSZ0q1EMuBPH_xk4-_VKcP1raOjJvSb5OinWCRVOHR7J6fw6LNQ5VijAwA6qX8GbJkHYEq06DYwuYpntCzqpTMZD20JpTDg2rre-7joyDV7WDrALyh_B177l3n6O-G3_S1XbshZtrrx-NRa17L2oYZ6YMZEWczSk2PpzF89f0UqItaamZbEosntxkrt82Kd4Pq1tyzRdJQTgc0auAQqSsmnfxZ56o15MryotjaW4cuf2TGy_CDWPebuaGD5A3jHm7M7dl8qZi3m7mph4gbyrm7c7cJG95-dQdbXu5V-blN__K6zY) - - [3n-spr 200ge cx7 mlx5 wireguard](https://csit.fd.io/report/#eNrtVl1rwyAU_TXZy3CoTUhe-rA2_6PYeNcGjJWrSdv9-plQuAmD7WWsUPui4jnX-3E4oA8nhJ0Hs86KTVZuMlm2Oi7Z6v01bmi8zLlkg3NM5m_xhGBAeWArq5h3yCTnB5BONJdyABVYZy4Fa12-C721YDwThaj2TDQMwjHe99qdW4RDr1ALzoM1_jzy9-OjVuOYW25vub8VQqjuA6GxvAUyABK4qJto7nglzk_dUIhCUBQza5IoAfysrt9bpsgPVB349hMofBodMZoo1QxsllnD1c3Q2yTLemLcW1f31PWPdHV31TU5tybg1eSc-vg-rVLzafX4Pq1S82n1zz4t6hd7wm76Bxf1F_3qK2U) + - [2n-icx 100ge e810cq avf ethip4udpgeneve](https://csit.fd.io/report/#eNrtVk2LwjAQ_TXdi4w02X7sxcO6_R8S01ELNc4maVF_vakUpt1lYQ-C0HpJQt6bzEwej8T5k8WNw3oVpesoX0cyr8owRO-fizDZ2skkzqAlApksw8pijcohSAOVPoOI4z1KEvghYv0Nqt1BRcnGN8Zg7SBLtiA0oD-EXejnpqQ9GmwRRBaIXcC2O9KUtsssv_rMv8pgtGw8o6G4EdKiZXBUNdPocBlw_uqF-cqi4oBBi0zx6AZF_atlDt5ZdURXXZFPCHfHuA4yMST0OK2_0ADt7zEv7oznakovTR-iKT1X0_nZdOounZ9JJ-5Rmc7vMR33PEWf_lCVXqo-2qtp8WZO9nj__6bFDR0OG4k) + - [3n-icx 100ge cx6 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlkFuwjAQRU-TbqpBiXGSVReF3AMFZwqRHDOyHRp6ehyENInaLqgobLyJI_9vz9hPX7LzB4sbh_otyVdJuUpE2TbhkyzfX8NgtRMyLeBIBEIuwp9FjbVDWBpo1QBZmu5QUKaGohmg00MOLcmN741B7aCQW8gUoN-H2Z2n3n2O-nbcwTR2LCTW10LfqrLa9J7V0MtMOaJlcdYk22h_Ys-vrbO_tljzgsmJ2OLRTZr66YTs_bB1h679Ql4QboZ1FSCwlKl5FX-iiXq9trK6OB5KjCKxvxCj_ycmYsZuIyaenTERM3ZPYg_ImIwZu42YfHbGZMzYPYlxxvLqxRxsd3kz5tUZE77cNg) + - [3n-spr 200ge cx7 mlx5 vxlan](https://csit.fd.io/report/#eNrtVcFuwjAM_Zrugjy1oaUnDrD-B0pTDyqlwXJCVfb1BKjkVtN24YCEuCRRnl_s5ycrPhwZdx7tOim2SblNVNk2cUmWm0Xc2HqVpyvoiUDln_HEaFF7hKXT4IlBpekeFWVmKHvUATo7FNBSvgsn59B6WOU1ZAYwHOJtP1jtwKq6qeMjnTaWHbiGrxnV15jxV3pBm1MQNBY1Q3pkAWfVShgdzhLznwahaEYtnIk0CQnoJ3X9LVUY36w79O0PCi02SnATbREoM_Nc4UwTdOxfWd0inuMhvT18yEN6joeDuQp78Qm8i3yp2Rt9o7dvD89bUX24I3e3_6-oLk0O_es) + - [3n-spr 200ge cx7 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlsGKgzAQhp_GXsoUTWM97aFd36OkOtsKMR2S6Lb79BtLYZRdFroU6SEXI_7_OJN8_BDnzxb3DvVbku-SYpeIoqnDI1lvl2Gx2gmZbqAnAiFX4c2iRuUQ1kaBIwsiTY8oKKsuRY_KQ6svOTQk974zBrWDjTxAVgH6U_h69NS5z0E_DD8xtR16ifd7rx-NWa07z2oYZ6L0aFmczMk2Ol3Z89f0XKIsKq4ZbYotHt1ort82yd4Pq1p0zRdyQTgc1quAgqWsmnbxVxqp95Mryptjbm4Uuf2TG83CTcS8PcxNvEDeRMzbk7nNkzcZ8_YwN_kCeZMxb0_mxnnLy4U52_Z2r8zLbx-f65Y) + - [3n-spr 200ge cx7 mlx5 wireguard](https://csit.fd.io/report/#eNrtVstuwyAQ_Br3UlFhYtdcemjq_4iI2SaWMEELdh5fH2xFWluV2kvVSKEXQMws-xiNhA8HhI0H85aV66xaZ6JqdVyy1ftz3NB4UfBXNjjHRPESTwgGlAe2sop5h0xwvgPh8uZUDaAC68ypZK0rNqG3FoxneZnLLcsbBmEf73vtji3Crleoc86DNf448rfjo1bjmFt83HJ_KYRQ3QdCY3kLZAAkcFE30dz-TJzvuqEQhaAoZtYkUQL4WV0_t0yRn6g68O0FKHwaHTGaKNUMbJZZw9nN0Nskq3pi3FtX96_rL-nq7qprcm5NwKvJOfXxfSpT86l8fJ_K1Hwq_9inZf1kD9hN_-CyvgJAfyvF) - reassembly - - [3n-icx 100ge e810cq dpdk reassembly](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEWx65BeOFDyD5Q4S2uROMZrCuH1uKHSJkJckNLmkIttecar2R2NZAqdx2fC5iHJdkm-S2Ru6rgkm8fbuPmGpEolHJ0Dqe7iyWODJSFsLBj9CSJN9yidwK1I9RvUrn4F7XsXOhCZ2FYgNGA4GKeMI9SRngbb0AfEm-pUx9gAJZLM7ve6jdVLImyrpgdb-5MO-XTW8UsUo_V7YDRKnSBH9AxOemCaO_TM-bszflBGofzip2FGA9JI0L_a52IvvmyRzBdyxWGyzNDRwhGop0JC70boeap5MTCW5Ldb_Z7Bbze333LN92X9ltfNt1zzvSS_Z8-3WvN9Wb_VdfOt1nwvyW_Od1bc2M63wz89K74B21hUdQ) + - [3n-icx 100ge e810cq dpdk reassembly](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYti12l64dCS_6gSZ2kt8lhstxC-HjdU2kSIC1LaHHKxLc94Nbujkex8a3HvsHqOkl2U7iKZmjIs0Wr7GDZbOaniNZyJQKqncLJYYe4QVg0Y_Qkijg8oSeBGxPodSirfQNuOfAsiEZsChAb0R0PKkEMd6LFvKvcB4aa41DGNhxydTNYHXYfquXNYF1UHTWkvOuTLVccvUYyWJ89okDpCzmgZHPXANDp2zPm7M36QB6H84qdhRj26gaB_tc_FXm1eozNfyBX7yTJDBwsHoB4L8R0N0OtU06xnzMlvWvyewG-a2m-55Pu2fsv75lsu-Z6T35PnWy35vq3f6r75Vku-5-Q35zvJHprW1v0_Pcm-AT9tVNU) -## CSIT-2402 Selected Performance Comparisons +## CSIT-2406 Selected Performance Comparisons -Comparisons 24.02 vs 23.10 -- [2n-icx 100ge e810cq avf 1c 64B PDR](https://csit.fd.io/comparisons/#eNqNkE0OwiAQhU9TN4YGsLVuXFh7AGO8AMGpadJSHGijnl7oj9jEhQkBZt43zPAM1CAtXPdRlkc8QygBQUlw92hzWI9ZA3aKL9g56bgekr6yatUCvXYz6o5eax-MvFN6wCBibXhCOeGbmFGC7jVhIOCVKlEEmitSyQdhlN6AawY7RuWdiL4MFbLFz9ipn4UdfZgWk15iY6rXEtkm-YKx9qmXxKk4T0Q2rLlXowX-4ZKjRAP2--PBiBHpRd3BD1-S2O1fvgz9V6rFZu9HS4s34Cl0zQ) +Comparisons 24.06 vs 24.02 +- [2n-icx 100ge e810cq avf 1c 64B PDR](https://csit.fd.io/comparisons/#eNqNkE0OwiAQhU_TbgyGYn_cuFB7AGO8AMGpIWkpDrRRTy_0R2ziwoQEHu8bZngGahAWrruoOESsQKgAQQlw52izX423BuykL9g567gaLn2lbNUCvXYz6rZeay9G3jk9YDCxNiylOWHpmjKC7jVuIOBSVcgDzRSR4kESSm_AdALbhIo74X0VKkSLn7EzP0ty9DIrJ7_CxsjXEsnTw4Kx9qmXxKk8T0QxrLlXozn-kZKjeAP2--MhiBHped3B71zy71yG_rFqsdn50bIybjtbS0Az6TdmuHnv) -## CSIT-2402 Selected Performance Coverage Data +## CSIT-2406 Selected Performance Coverage Data -CSIT-2402 VPP v24.02 coverage data -- [2n-icx 200ge cx7 mlx5 ip4](https://csit.fd.io/coverage/#eNpVjsEOwiAQRL8GLwaDK4RTD9r-h9ngxpIgJYBI_94SD9TLJjNvZjOJHJlsFz8wfWOgo0vbZZfr8SdACmgGjM14vHOnJYQ_Uih2CPIkgMftOybqsTCvu4zn1lQOQjwJwtlUXQgzf7mqegMjYa_YIJvQ0yHNy-fuMJM368BU2763WkpNXye-PaE) +CSIT-2406 VPP v24.06 coverage data +- [2n-icx 200ge cx7 mlx5 ip4](https://csit.fd.io/coverage/#eNpVjsEOwiAQRL8GLwaDWyinHqz9D0NwY0mQEkCkf98SD9TLJjNvZjMRLepkFjcQORKQwcb9ku52_gngrK8G3Kvx_KRGs_d_JGNoEPiF9TTs31XEFvPzesg4anShwNgLwV91kRlVom9bRGuogKpVjOdVyOkU5-X7sCqh0-tARN1-tGpKTBsssj2p) ## Further Information diff --git a/docs/content/release_notes/current/dpdk_performance.md b/docs/content/release_notes/current/dpdk_performance.md index 97e757fe50..4ef0f6fd8d 100644 --- a/docs/content/release_notes/current/dpdk_performance.md +++ b/docs/content/release_notes/current/dpdk_performance.md @@ -3,23 +3,23 @@ title: "DPDK Performance" weight: 2 --- -# CSIT 24.02 - DPDK Performance +# CSIT 24.06 - DPDK Performance 1. TEST FRAMEWORK - - **CSIT test environment** version has been updated to ver. 14, see + - **CSIT test environment** version has been updated to ver. 15, see [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). 2. DPDK PERFORMANCE TESTS - No updates 3. DPDK RELEASE VERSION CHANGE - - Version 23.11 is now tested. + - Version 24.03 is now tested. # Known Issues -List of known issues in CSIT 24.02 for DPDK performance tests: +List of known issues in CSIT 24.06 for DPDK performance tests: ## New -List of new issues in CSIT 24.02 for DPDK performance tests: +List of new issues in CSIT 24.06 for DPDK performance tests: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- @@ -27,12 +27,16 @@ List of new issues in CSIT 24.02 for DPDK performance tests: ## Previous +List of known issues in CSIT 24.06 for DPDK performance tests: + **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- 1 | | ## Fixed +List of fixed issues in CSIT 24.06 for DPDK performance tests: + **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- 1 | | diff --git a/docs/content/release_notes/current/trex_performance.md b/docs/content/release_notes/current/trex_performance.md index d0f82fd2e7..dc859fa658 100644 --- a/docs/content/release_notes/current/trex_performance.md +++ b/docs/content/release_notes/current/trex_performance.md @@ -3,10 +3,10 @@ title: "TRex Performance" weight: 3 --- -# CSIT 24.02 - TRex Performance +# CSIT 24.06 - TRex Performance 1. TEST FRAMEWORK - - **CSIT test environment** version has been updated to ver. 14, see + - **CSIT test environment** version has been updated to ver. 15, see [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). 2. TREX TESTS - No updates @@ -17,7 +17,7 @@ weight: 3 ## New -List of new issues in CSIT 24.02 for TRex performance tests: +List of new issues in CSIT 24.06 for TRex performance tests: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- @@ -25,7 +25,7 @@ List of new issues in CSIT 24.02 for TRex performance tests: ## Previous -List of known issues in CSIT 24.02 for TRex performance tests +List of known issues in CSIT 24.06 for TRex performance tests: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- @@ -33,7 +33,7 @@ List of known issues in CSIT 24.02 for TRex performance tests ## Fixed -List of known issues in CSIT 24.02 for TRex performance tests +List of fixed issues in CSIT 24.06 for TRex performance tests: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- diff --git a/docs/content/release_notes/current/vpp_device.md b/docs/content/release_notes/current/vpp_device.md index 3ade1c6b68..d6a9d91146 100644 --- a/docs/content/release_notes/current/vpp_device.md +++ b/docs/content/release_notes/current/vpp_device.md @@ -3,15 +3,18 @@ title: "VPP Device" weight: 4 --- -# CSIT 24.02 - VPP Device +# CSIT 24.06 - VPP Device 1. TEST FRAMEWORK - - **CSIT test environment** version has been updated to ver. 14, see + - **CSIT test environment** version has been updated to ver. 15, see [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). +2. DEVICE TESTS + - Added Intel-X710 to 1n-spr and Mellanox-CX6DX to 1n-alt testbed. + - Migrated some tests to the new NICs to avoid spurious failures. # Known Issues -List of known issues in CSIT 24.02 for VPP functional tests in VPP Device: +List of known issues in CSIT 24.06 for VPP functional tests in VPP Device: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- @@ -20,7 +23,7 @@ List of known issues in CSIT 24.02 for VPP functional tests in VPP Device: ## New -List of new issues in CSIT 24.02 for VPP functional tests in VPP Device: +List of new issues in CSIT 24.06 for VPP functional tests in VPP Device: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- diff --git a/docs/content/release_notes/current/vpp_performance.md b/docs/content/release_notes/current/vpp_performance.md index 3b3711039e..3ae7efb494 100644 --- a/docs/content/release_notes/current/vpp_performance.md +++ b/docs/content/release_notes/current/vpp_performance.md @@ -3,22 +3,30 @@ title: "VPP Performance" weight: 1 --- -# CSIT 24.02 - VPP Performance +# CSIT 24.06 - VPP Performance 1. TEST FRAMEWORK - - **CSIT test environment** version has been updated to ver. 14, see + - **CSIT test environment** version has been updated to ver. 15, see [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). - **General Code Housekeeping**: Ongoing code optimizations and bug fixes. - - **Trending and release testing**: Ndrpdr tests use newer code - (MLRsearch 1.2.1) and configuration, gaining more stability and speed. -1. VPP PERFORMANCE TESTS - - Added 2n-c7gn and 3n-icxd testbeds. -2. PRESENTATION AND ANALYTICS LAYER - - [Performance dashboard](https://csit.fd.io/) got updated with the - possibility to [search in tests](https://csit.fd.io/search/). - - [Per Release Performance Comparisons](https://csit.fd.io/comparisons/) got - updated with the function removing extreme outliers from data presented in - the comparison table. +2. VPP PERFORMANCE TESTS + - Added tests: + - Added memif+DMA tests; added 1518B and 4c memif testcases. + - Added nginx+DMA tests; added 2048B testcases. + - Added IPsec hwasync tests to 3n-icxd and 3n-snr. + - Added IPsec tests to cover more encryption algorithms and other settings. + - Added more SOAK tests. + - Added selected 6-port tests for 3na-spr. + - Edited tests: + - Selected single-flow tests now use single worker even if SMT is on. + - IPsecHW tests now use rxq ratio of 2. + - This means one worker reads only from one of two ports. + - This workaround avoids some inefficiencies, + - but still does not reach the expected performance on 3nb-spr. + - 1518B tests with encapsulation overhead now properly use no-multi-seg. + - Added TX checksum offload to hoststack tests missing it. +3. PRESENTATION AND ANALYTICS LAYER + - Detailed views added to comparison tables. # Known Issues @@ -32,53 +40,60 @@ but was not detected/recognized/reported enough back then. Also, issues previously thought fixed but now reopened are listed here. **#** | **JiraID** | **Issue Description** -------|--------------------------------------------------|-------------------------------------------------------------- - 1 | [CSIT-1845](https://jira.fd.io/browse/CSIT-1845) | AVF 9000B any ndrpdr test may start failing due to packets not arriving in one or both directions. - 2 | [CSIT-1946](https://jira.fd.io/browse/CSIT-1946) | Ipsec hwasync fails with large scale and multiple queues. - 3 | [CSIT-1947](https://jira.fd.io/browse/CSIT-1947) | VPP crash in udp nat avf 4c tests. - 4 | [CSIT-1948](https://jira.fd.io/browse/CSIT-1948) | NICs do not consistently distribute tunnels over RXQs depending on model or plugin. - 5 | [CSIT-1950](https://jira.fd.io/browse/CSIT-1950) | 9000B tests with high encap overhead see fragmented packets. - 6 | [CSIT-1951](https://jira.fd.io/browse/CSIT-1951) | Combination of AVF and vhost drops all 9000B packets. - 7 | [CSIT-1954](https://jira.fd.io/browse/CSIT-1954) | 3n-icx: 9000B AVF ip6 tests show zero traffic in one direction due to no free tx slots. +------|--------------------------------------------------|--------------------------------------------------------------------------- + 1 | [CSIT-1877](https://jira.fd.io/browse/CSIT-1877) | 3n-tsh: VM tests too slow to boot VM, rarely, despite increased timeout. + 2 | [CSIT-1884](https://jira.fd.io/browse/CSIT-1884) | 2n-clx, 2n-icx: All NAT44DET NDR PDR IMIX over 1M sessions BIDIR tests failing to create enough sessions. + 3 | [VPP-2118](https://jira.fd.io/browse/VPP-2118) | 3n spr: Unusable performance of ipsec tests with SHA_256_128. + 4 | [CSIT-1960](https://jira.fd.io/browse/CSIT-1960) | 2n-zn2: Geneve sometimes loses one direction of traffic. + 5 | [CSIT-1961](https://jira.fd.io/browse/CSIT-1961) | Some tests have too long ramp-up trials. + 6 | [CSIT-1962](https://jira.fd.io/browse/CSIT-1962) | 3n-icx hoststack: Udpquicscale tests sometimes fail with various symptoms. + 7 | [CSIT-1963](https://jira.fd.io/browse/CSIT-1963) | 3n-icxd: Various symptoms pointing to hardware (cable/nic/driver) issues. + 8 | [CSIT-1964](https://jira.fd.io/browse/CSIT-1964) | 3nb-spr: Wireguardhw tests are likely to crash. + 9 | [CSIT-1965](https://jira.fd.io/browse/CSIT-1965) | Occasional failure on 1518B CX5: Trex failed to send message. + 10 | [VPP-2121](https://jira.fd.io/browse/VPP-2121) | sw_interface_add_del_address: avf process node failed to reply in 5 seconds + 11 | [CSIT-1966](https://jira.fd.io/browse/CSIT-1966) | 3n-snr: Increased heap size in ipsec policy tests prevents VPP from starting. + 12 | [CSIT-1967](https://jira.fd.io/browse/CSIT-1967) | 3na-spr: Unable to configure large MTU for 9000B tests. ## Previous Issues reported in previous releases which still affect the current results. **#** | **JiraID** | **Issue Description** -------|--------------------------------------------------|-------------------------------------------------------------- - 1 | [CSIT-1782](https://jira.fd.io/browse/CSIT-1782) | Multicore AVF tests are failing when trying to create interface. Frequency is reduced by CSIT workaround, but occasional failures do still happen. - 2 | [CSIT-1785](https://jira.fd.io/browse/CSIT-1785) | NAT44ED tests failing to establish all TCP sessions. At least for max scale, in allotted time (limited by session 500s timeout) due to worse slow path performance than previously measured and calibrated for. CSIT removed the max scale NAT tests to avoid this issue. - 3 | [CSIT-1795](https://jira.fd.io/browse/CSIT-1795) | Ocassionally not all DET44 sessions have been established: 4128767 != 4128768 - 4 | [CSIT-1802](https://jira.fd.io/browse/CSIT-1802) | All testbeds: AF-XDP - NDR tests failing from time to time on small loss. - 5 | [CSIT-1804](https://jira.fd.io/browse/CSIT-1804) | 3n-tsh: NDR fails on ierrors. - 6 | [CSIT-1849](https://jira.fd.io/browse/CSIT-1849) | 2n-clx, 2n-icx: UDP 16m TPUT tests fail to create all sessions. - 7 | [CSIT-1881](https://jira.fd.io/browse/CSIT-1881) | 2n-icx: NFV density tests ocassionally breaks VPP which fails to start. - 8 | [CSIT-1886](https://jira.fd.io/browse/CSIT-1886) | 3n-icx: Wireguard tests with 100 and more tunnels are failing PDR criteria. - 9 | [CSIT-1892](https://jira.fd.io/browse/CSIT-1892) | 3n-alt: Unexpected two-band structure of ipsec and vxlan. - 10 | [CSIT-1896](https://jira.fd.io/browse/CSIT-1896) | Depending on topology, l3fwd avoids dut-dut link. - 11 | [CSIT-1901](https://jira.fd.io/browse/CSIT-1901) | 3n-icx: Negative ipackets on TB38 AVF 4c l2patch. - 12 | [CSIT-1904](https://jira.fd.io/browse/CSIT-1904) | DPDK 23.03 testpmd startup fails on some testbeds. - 13 | [CSIT-1906](https://jira.fd.io/browse/CSIT-1906) | Zero traffic with cx7 rdma. Testing migrated to mlx5-core on all Mellanox NICs. - 14 | [VPP-2077](https://jira.fd.io/browse/VPP-2077) | IP fragmentation: running_fragment_id is not thread safe. Causes reduced performance and failures in gtpu reassembly tests. - 15 | [CSIT-1914](https://jira.fd.io/browse/CSIT-1914) | TRex does not produce latency data on ICE NICs. - 16 | [CSIT-1915](https://jira.fd.io/browse/CSIT-1915) | The 2n-icx testbeds to not have the same performance. - 17 | [CSIT-1916](https://jira.fd.io/browse/CSIT-1916) | Poor CPU scaling on 2n-zn2 RDMA. - 18 | [CSIT-1917](https://jira.fd.io/browse/CSIT-1917) | TRex STL performance is unstable at high pps due to unsent packets. - 19 | [CSIT-1921](https://jira.fd.io/browse/CSIT-1921) | Two-band structure in SRv6, causes PDR failure in rare cases. - 20 | [CSIT-1922](https://jira.fd.io/browse/CSIT-1922) | 2n-tx2: AF_XDP MRR failures. On other testbeds MRR regressions and PDR failures. - 21 | [CSIT-1924](https://jira.fd.io/browse/CSIT-1924) | An l3fwd error in 200Ge2P1Cx7Veat-Mlx5 test with 9000B. - 22 | [CSIT-1935](https://jira.fd.io/browse/CSIT-1935) | Zero traffic reported in udpquic tests due to session close errors. - 23 | [CSIT-1936](https://jira.fd.io/browse/CSIT-1936) | TRex occasionally sees link down in L2 perf tests. - 24 | [CSIT-1937](https://jira.fd.io/browse/CSIT-1937) | Small but frequent loss in ASTF UDP on cx7 mlx5. - 25 | [CSIT-1938](https://jira.fd.io/browse/CSIT-1938) | 3n-alt: High scale ipsec policy tests may crash VPP. - 26 | [CSIT-1939](https://jira.fd.io/browse/CSIT-1939) | 3na-spr, 2n-zn2: VPP fails to start in first test cases. - 27 | [CSIT-1941](https://jira.fd.io/browse/CSIT-1941) | TRex may wrongly detect link bandwidth. - 28 | [CSIT-1942](https://jira.fd.io/browse/CSIT-1942) | 3nb-spr hoststack: Interface not up after first test. - 29 | [CSIT-1943](https://jira.fd.io/browse/CSIT-1943) | IMIX 4c tests may fail PDR due to ~10% loss. - 30 | [CSIT-1944](https://jira.fd.io/browse/CSIT-1944) | Memif LXC: unrecognized option '--no-validate'. - 31 | [VPP-2090](https://jira.fd.io/browse/VPP-2090) | MRR < PDR: DPDK plugin with MLX5 driver does not read full queue. - 32 | [VPP-2091](https://jira.fd.io/browse/VPP-2091) | Memif crashes with jumbo frames. +------|--------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------- + 1 | [CSIT-1785](https://jira.fd.io/browse/CSIT-1785) | NAT44ED tests failing to establish all TCP sessions. At least for max scale, in allotted time (limited by session 500s timeout) due to worse slow path performance than previously measured and calibrated for. CSIT removed the max scale NAT tests to avoid this issue. + 2 | [CSIT-1795](https://jira.fd.io/browse/CSIT-1795) | Ocassionally not all DET44 sessions have been established: 4128767 != 4128768. + 3 | [CSIT-1802](https://jira.fd.io/browse/CSIT-1802) | All testbeds: AF-XDP - NDR tests failing from time to time on small loss. + 4 | [CSIT-1804](https://jira.fd.io/browse/CSIT-1804) | 3n-tsh: NDR fails on ierrors. + 5 | [CSIT-1845](https://jira.fd.io/browse/CSIT-1845) | AVF 9000B any ndrpdr test may start failing due to packets not arriving in one or both directions. + 6 | [CSIT-1886](https://jira.fd.io/browse/CSIT-1886) | 3n: Wireguard tests with 100 and more tunnels are failing PDR criteria. + 7 | [CSIT-1892](https://jira.fd.io/browse/CSIT-1892) | 3n-alt: Unexpected two-band structure of ipsec and vxlan. + 8 | [CSIT-1896](https://jira.fd.io/browse/CSIT-1896) | Depending on topology, l3fwd avoids dut-dut link. + 9 | [CSIT-1901](https://jira.fd.io/browse/CSIT-1901) | 2n-icx 3n-icx: Trex may report negative ipackets on high-performance AVF trial. + 10 | [CSIT-1904](https://jira.fd.io/browse/CSIT-1904) | DPDK 23.03 testpmd startup fails on some testbeds. + 11 | [CSIT-1906](https://jira.fd.io/browse/CSIT-1906) | Zero traffic with cx7 rdma. Testing migrated to mlx5-core on all Mellanox NICs. + 12 | [VPP-2077](https://jira.fd.io/browse/VPP-2077) | IP fragmentation: running_fragment_id is not thread safe. Causes reduced performance and failures in gtpu reassembly tests. + 13 | [CSIT-1914](https://jira.fd.io/browse/CSIT-1914) | TRex does not produce latency data on ICE NICs. + 14 | [CSIT-1915](https://jira.fd.io/browse/CSIT-1915) | The 2n-icx testbeds do not have the same performance. + 15 | [CSIT-1916](https://jira.fd.io/browse/CSIT-1916) | Poor CPU scaling on 2n-zn2 RDMA. + 16 | [CSIT-1917](https://jira.fd.io/browse/CSIT-1917) | TRex STL performance is unstable at high pps due to unsent packets. + 17 | [CSIT-1922](https://jira.fd.io/browse/CSIT-1922) | 2n-tx2: AF_XDP MRR failures. On other testbeds MRR regressions and PDR failures. + 18 | [CSIT-1924](https://jira.fd.io/browse/CSIT-1924) | An l3fwd error in 200Ge2P1Cx7Veat-Mlx5 test with 9000B. + 19 | [CSIT-1929](https://jira.fd.io/browse/CSIT-1929) | Lossy trials in nat udp mlx5 tests. + 20 | [CSIT-1935](https://jira.fd.io/browse/CSIT-1935) | rls2310: Zero traffic reported in udpquic tests due to session close errors. + 21 | [CSIT-1936](https://jira.fd.io/browse/CSIT-1936) | TRex occasionally sees link down in L2 perf tests. + 22 | [CSIT-1938](https://jira.fd.io/browse/CSIT-1938) | 3n-alt: High scale ipsec policy tests may crash VPP. + 23 | [CSIT-1941](https://jira.fd.io/browse/CSIT-1941) | TRex may wrongly detect link bandwidth. + 24 | [CSIT-1942](https://jira.fd.io/browse/CSIT-1942) | 3nb-spr hoststack: Interface not up after first test. + 25 | [CSIT-1943](https://jira.fd.io/browse/CSIT-1943) | IMIX 4c tests may fail PDR due to ~10% loss. + 26 | [CSIT-1944](https://jira.fd.io/browse/CSIT-1944) | Memif LXC: unrecognized option '--no-validate'. + 27 | [VPP-2090](https://jira.fd.io/browse/VPP-2090) | MRR < PDR: DPDK plugin with MLX5 driver does not read full queue. + 28 | [CSIT-1946](https://jira.fd.io/browse/CSIT-1946) | Ipsec hwasync fails with large scale and multiple queues. + 29 | [CSIT-1947](https://jira.fd.io/browse/CSIT-1947) | Rare VPP crash in nat avf tests. + 30 | [VPP-2091](https://jira.fd.io/browse/VPP-2091) | Memif crashes VPP in container with jumbo frames. + 31 | [CSIT-1948](https://jira.fd.io/browse/CSIT-1948) | NICs do not consistently distribute tunnels over RXQs depending on model or plugin. + 32 | [CSIT-1950](https://jira.fd.io/browse/CSIT-1950) | 9000B tests with encap overhead and non-dpdk plugins see fragmented packets. + 33 | [CSIT-1951](https://jira.fd.io/browse/CSIT-1951) | Combination of AVF and vhost drops all 9000B packets. + 34 | [CSIT-1953](https://jira.fd.io/browse/CSIT-1953) | 3n-icx 3nb-spr: Failed to enable GTPU offload RX. ## Fixed @@ -86,14 +101,14 @@ Issues reported in previous releases which were fixed in this release: **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- - 1 | [CSIT-1883](https://jira.fd.io/browse/CSIT-1883) | 3n-snr: All hwasync wireguard tests failing when trying to verify device. - 2 | [CSIT-1940](https://jira.fd.io/browse/CSIT-1940) | Hardware acceleration does not work yet. - 3 | [VPP-2087](https://jira.fd.io/browse/VPP-2087) | VPP crash and other symptoms in tests with AVF, jumbo packets. - 4 | [VPP-2088](https://jira.fd.io/browse/VPP-2088) | virtio: Bad CLI argument parsing introduced with tx-queue-size. + 1 | [CSIT-1782](https://jira.fd.io/browse/CSIT-1782) | Multicore AVF tests are failing when trying to create interface. Frequency is reduced by CSIT workaround, but occasional failures do still happen. + 2 | [CSIT-1881](https://jira.fd.io/browse/CSIT-1881) | 2n-icx: NFV density tests ocassionally breaks VPP which fails to start. + 3 | [CSIT-1921](https://jira.fd.io/browse/CSIT-1921) | Two-band structure in SRv6, causes PDR failure in rare cases. + 4 | [CSIT-1939](https://jira.fd.io/browse/CSIT-1939) | 3na-spr, 2n-zn2: VPP fails to start in first test cases. # Root Cause Analysis for Regressions -List of RCAs in CSIT 24.02 for VPP performance regressions. +List of RCAs in CSIT 24.06 for VPP performance regressions. Not listing differences caused by known issues (uneven worker load due to randomized RSS or other per-worker issues). Also not listing tests which historically show large performance variance. @@ -105,4 +120,5 @@ they will not be re-listed in the next release report. **#** | **JiraID** | **Issue Description** ------|--------------------------------------------------|-------------------------------------------------------------- - 1 | [VPP-2099](https://jira.fd.io/browse/VPP-2099) | Bump of rdma-core to 49.0 decreased performance. + 1 | [CSIT-1958](https://jira.fd.io/browse/CSIT-1958) | 3n-icx 3na-spr: Mixed performance impact of 40373 around 2024-04-20. + 2 | [CSIT-1959](https://jira.fd.io/browse/CSIT-1959) | Explain change in c6in performance. diff --git a/docs/content/release_notes/previous/_index.md b/docs/content/release_notes/previous/_index.md index a1b468f16c..8b8ee75add 100644 --- a/docs/content/release_notes/previous/_index.md +++ b/docs/content/release_notes/previous/_index.md @@ -7,6 +7,7 @@ weight: 2 # Previous Releases +- [CSIT rls2402]({{< relref "csit_rls2402" >}}) - [CSIT rls2306]({{< relref "csit_rls2306" >}}) - [CSIT rls2302]({{< relref "csit_rls2302" >}}) - [CSIT rls2210](https://s3-docs.fd.io/csit/rls2210/report/) diff --git a/docs/content/release_notes/previous/csit_rls2302/_index.md b/docs/content/release_notes/previous/csit_rls2302/_index.md index 34425fbc69..f1ac4a2e6d 100644 --- a/docs/content/release_notes/previous/csit_rls2302/_index.md +++ b/docs/content/release_notes/previous/csit_rls2302/_index.md @@ -2,7 +2,7 @@ bookCollapseSection: true bookFlatSection: false title: "CSIT rls2302" -weight: 3 +weight: 4 --- # CSIT rls2302 diff --git a/docs/content/release_notes/previous/csit_rls2306/_index.md b/docs/content/release_notes/previous/csit_rls2306/_index.md index 6578ef91f7..dd43bbeb1c 100644 --- a/docs/content/release_notes/previous/csit_rls2306/_index.md +++ b/docs/content/release_notes/previous/csit_rls2306/_index.md @@ -2,7 +2,7 @@ bookCollapseSection: true bookFlatSection: false title: "CSIT rls2306" -weight: 2 +weight: 3 --- # CSIT-2306 Release Report diff --git a/docs/content/release_notes/previous/csit_rls2310/_index.md b/docs/content/release_notes/previous/csit_rls2310/_index.md index 6be4f8811e..51ee084abe 100644 --- a/docs/content/release_notes/previous/csit_rls2310/_index.md +++ b/docs/content/release_notes/previous/csit_rls2310/_index.md @@ -2,7 +2,7 @@ bookCollapseSection: true bookFlatSection: false title: "CSIT rls2310" -weight: 1 +weight: 2 --- # CSIT-2310 Release Report diff --git a/docs/content/release_notes/previous/csit_rls2402/_index.md b/docs/content/release_notes/previous/csit_rls2402/_index.md new file mode 100644 index 0000000000..868ead0c39 --- /dev/null +++ b/docs/content/release_notes/previous/csit_rls2402/_index.md @@ -0,0 +1,118 @@ +--- +bookCollapseSection: true +bookFlatSection: false +title: "CSIT rls2402" +weight: 1 +--- + +# CSIT-2402 Release Report + +This section includes release notes for FD.io CSIT-2402. The CSIT report +was published on **Mar-13 2024**. The release plan is published on +[CSIT wiki](https://wiki.fd.io/view/CSIT/csit2402_plan) pages. + +## CSIT-2402 Release Notes + +- [VPP Performance]({{< relref "vpp_performance" >}}) +- [DPDK Performance]({{< relref "dpdk_performance" >}}) +- [TRex Performance]({{< relref "trex_performance" >}}) +- [VPP Device]({{< relref "vpp_device" >}}) + +## CSIT-2402 Release Data + +To access CSIT-2402 Release data please use following web resources: + +- [CSIT Per Release Performance](https://csit.fd.io/report/) + - `CSIT Release` > `rls2402` + - `DUT` > `vpp` + - `DUT Version` > `24.02-release` + - `Infra` > `testbed-nic-driver of choice` + - `Area` > `IPv4 Routing` `IPv4 Tunnels` `IPv6 Routing` `Hoststack` ... + - `Test` > `test of chioce` + - `Frame Size` > `64B` `78B` + - `Number of Cores` > `1C` `2C` `4C` + - `Test Type` > `MRR` `NDR` `PDR` +- [CSIT Per Release Comparisons](https://csit.fd.io/comparisons/) for VPP + v24.02 vs v23.10 + - `REFERENCE VALUE` + - `DUT` > `vpp` + - `CSIT and DUT version` > `rls2402-23.10-release` + - `Infra` > `testbed-nic-driver of choice` + - `Frame Size` > `64B` `78B` + - `Number of Cores` > `1C` `2C` `4C` + - `Measurement` > `Latency` `MRR` `NDR` `PDR` + - `COMPARED VALUE` + - `Parameter` > `Release and Version` + - `Value` > `rls2402-24.02-release` +- [CSIT Per Release Coverage Data](https://csit.fd.io/coverage/) + - `CSIT Release` > `rls2402` +- [CSIT Search Tests](https://csit.fd.io/search/) + - `Data Type` > `iterative` + - `DUT` > `vpp` + - `Release` > `rls2402` + - `Type a Regular Expression` > `2n-zn2 -1c ethip4-ip4base-[mrr|ndrpdr]` + ".*" can be replaced by " " (white space). + - `Choose a cell in the table` > A corresponding graph(s) is displayed. + - `Click a datapoint in the graph` > Detailed information is displayed. + +## CSIT-2402 Selected Performance Tests + +CSIT-2402 VPP v24.02 Performance Tests: + +- ip4 + - [2n-icx 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsrUO4cGjJfyDjbGlEmpq1G1G-HreqtIkAqUgtvfjgl2asHe9oJIe4YXoO1D0W5aKoFgVWbZOmYja_TQt3AY1CGLwHNHdpx9SRDQTYQ-s-QCv1Sug1PWjl3sEOS2i9gXvzAtoBxdX-lEZwtiNUb8B9A33D-xL4dCzxrZ6gzTYKmlRMkIFYwIk8ofnVbsT5TbTwLZOVC0m5QJHCSMzPbxP2ku2aQvtJciV1RXCXGi-QdtM6cedH6LFhVX1g_JNLPrv0N5f85VzCnKXTXcJrZQlzls7l0gWzZHKWTnfJXCtLJmfpXC5Jlsr6pt_w-vDXK-sv2WmuRg) + - [2n-spr 100ge e810cq avf ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_BrnUrZIWznupYem_o-iypvG1HHUlWpIv75KCKxNUkghaS466MWM2NEOAwpxw_QaqHsqykVRLQqs2iZNxcPzXVq4C2gUwuA9oLlPO6aObCDAHoJn0Eq9E3pNj1q5T7DDElpvYG7eQDuguNqd0gjOdoTqA7hvoG94VwJfDiWO6gnafEVBk4oJMhALOJEnNL_ajji_iRa-ZbJyISkXKFIYiTn9NmEv2a4ptN8kV1JXBHep8QJpN60Tt36EHhpW1XvGP7nks0t_c8lfzyXMWTrfJbxVljBn6VIuXTFLJmfpfJfMrbJkcpYu5ZJkqaxn_YbX-79eWf8ADdavEg) + - [2n-spr 100ge e810cq dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEX24hAuHFryD2TshUZN08U2lcrrcatKmwg4RGrpxYc4tmZXM97RSI5pG-glUv9U1cuqWVbYdD4v1f3iNv9CH9EohB0zoLnLu0A92UiAA0QOoJV6J2RNj1q5D_Ds19CxgQfzCtoBpdXhlL_obE-o1hAGD4MPBw58PnH8IBTUfyZBs4wJsqMg4ESflPFqP6r5U7U02EBWOrJ0gRLFkZrfLyfVb8FuKHZfJC15LIK7PHqBtJvypD2P0NPEmvZY8V8-cfFppk98QZ-w5GmGT3i1PGHJ09l8umSeTMnTDJ_M1fJkSp7O5pPkqW5vhm3YHN99dfsNi3az2g) + - [2n-spr 200ge cx7 mlx5 ip4scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UjbYG7k-9dDU_xEUeZuYyo5YqSbp11cJgbVpezDkcdHBssTsMqMdBuTDnmntyb5m5SqrVhlWbROXbPn2HH9sPaocYXAOUC3ijsmS9gTYg3cMmOdbQleYQzWQDtDZQwmtU_CiNlAYoLA7neLnjbaE-Sdw30Df8IkE3y8kvxgFbb6CoFHHBBmIBZwIlDK3O45q_pctHZpJS0vULlAgP5Lz9-2k-oN1R779JmmJcxHcxOELVJgpTzi6EXoZWVWfK-7mlEtOzXXK3dIpTJma4xQ-LlOYMnU9p26aKZUyNccp9bhMqZSp6zklmSrrp37P3fkNWNY_glq9yg) + - [2n-c6in 200ge c6in.4xl ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91qwzAMhZ8muxkasZo0u9nFurzH8GxtDU1dYaeF7unnhIISuo0V2rUXvsgf5wQp-jiIhG7j6TVQ-5SVi6xaZFg1Np6y2fN9vPg2YJEj7JgBi4d456klHQjQgZk3DjDPP0ixIqfBsl1BwwWoUj2-gTJA3bJ_jkcwuiXMV-CdBWd9XwNfDjWOCopqt52osY2JsiMv4qQ_sfFyP_L80LXYtSct_ti4SB2FUS_ff5q4371eU2g-SV4ZxiIOE0c_Es20UrfnkXqYWFUPjv_ixInTiZz4gpww5ekETni1PGHK09k4XSZP8yJtpyNKcSi3tJt-Z8SJ0Q3spZ5R2kp_Z4RXylHaSOdiJDkq6zu38evhv6msvwDzBpLJ) + - [2n-c7gn 100ge c7gn ena dpdk ip4scale20k-rnd](https://csit.fd.io/report/#eNrtl91qwzAMhZ8muxkasZosu9nFurzH8GytDU1dYaeF7unnhIISuo0V2rUXvsgf5wQp-jiIhG7j6S1Q-5yV86yaZ1g1Np6y2ct9vPg2YJEj7JgBi4d456klHQjQgakWDlSeL0ixIqfBsl1BwwWoUj29gzJA3bJ_jkcwuiXMV-CdBWd9XwNfDzWOCopqt52osY2JsiMv4qQ_sfFyP_L80LXYtSct_ti4SB2FUS_ff5q4P7xeU2g-SV4ZxiIOE0c_Es20UrfnkXqYWFUPjv_ixInTiZz4gpww5ekETni1PGHK09k4XSZPj0XaTkeU4lBuaTf9zogToxvYSz2jtJX-zgivlKO0kc7FSHJU1ndu49fDf1NZfwEWdpKp) +- ip6 + - [2n-icx 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstOwzAQ_JpwQYvsrUN64UCb_0DG2dKINDVrE1G-HreqtIkAqUgtvfjgl2asHe9oJIe4ZXoK1D0U5aKoFgVWbZOmYvZ4mxbuAhqFMHgPaO7SjqkjGwiwh9Z9gFbqhdBrmmvl3sAOK2j9PVTzZ9AOKK73pzSCsx2hegXuG-gb3pfA5bHEt3qCNu9R0KRiggzEAk7kCc2vdyPOb6KFb5msXEjKBYoURmJ-fpuwV2w3FNpPkiupK4K71HiBtJvWiTs_Qo8Nq-oD459c8tmlv7nkL-cS5iyd7hJeK0uYs3Quly6YJZOzdLpL5lpZMjlL53JJslTWN_2WN4e_Xll_AXFKrso) + - [2n-spr 100ge e810cq avf ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVstqwzAQ_Br3UrZIG7nOpYek_o-iypvG1HHUlWJIv75KCKxNW0ghaS466MWM2NEOAwpxy_QSqHsqymVRLQus2iZNxWxxnxbuAhqFMHgPaB7SjqkjGwiwh-AZtFJvhF7TXCv3AXZYQesfoZq_gnZAcX04pRGc7QjVO3DfQN_woQQ-n0p8qydos4uCJhUTZCAWcCJPaH69H3F-Ey18y2TlQlIuUKQwEvPz24S9Yruh0H6SXEldEdylxguk3bRO3PsRempYVR8Z_-SSzy79zSV_PZcwZ-l8l_BWWcKcpUu5dMUsmZyl810yt8qSyVm6lEuSpbK-67e8Of71yvoLpaivlg) + - [2n-spr 100ge e810cq dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEX24pBeOFDyD2TshUZN08U2lcrrcatKmwg4RGrpxYc4tmZXM97RSI5pG-glUv9Y1cuqWVbYdD4v1f3Tbf6FPqJRCDtmQHOXd4F6spEAB4gcQCv1TsiaFlq5D_Ds19DxAzSLV9AOKK0Op_xFZ3tCtYYweBh8OHDg84njB6Gg_jMJmmVMkB0FASf6pIxX-1HNn6qlwQay0pGlC5QojtT8fjmpfgt2Q7H7ImnJYxHc5dELpN2UJ-15hJ4m1rTHiv_yiYtPM33iC_qEJU8zfMKr5QlLns7m0yXzZEqeZvhkrpYnU_J0Np8kT3V7M2zD5vjuq9tvJi20Xg) + - [2n-spr 200ge cx7 mlx5 ip6scale20k-rnd](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEXJ4mAuHFryD2SchUY4qbU2UcvrcatKmwg4RGrpxYc4tmZXM97RSA5xy_QSyD0V9brQ6wJ116aluF_dph-7gKpEGL0HVHdpx-TIBAIcIHgGLMt3Ql_ZnR7JROjdrobOP4B-fIXKAsXN4ZS-YI0jLD-AhxaGlg8k-Hwi-cEoaPsZBU06ZshILOBMoJT5zX5S87ds6TBMRlqSdoEihYmc328n1W9segrdF0lLmovgNg1foMrOeeLeT9DTyHRzrPg3p3x2aqlT_pJOYc7UEqfwepnCnKnzOXXRTKmcqSVOqetlSuVMnc8pyVTd3Axb7o9vwLr5Bh_nvk4) + - [2n-c6in 200ge c6in.4xl ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_Br3UrZY2zjqpYem_o-iSNvGxFGEpAbSr49iAmuTBBqwmx508IsZs-MdhsEhbj19BGpfi2pRyEWBsjHpVDy_PaaLbwPOSoSdc4Czp3TnqSUVCNCCnjcWsCy_SDhBVoFxZg2Nm4OoxMsShAaKq-NzOoJWLWG5Bm8NWOOPM_D9NONsIKPmOzKaZAyQHXkGB_qY5lb7HueKaqYrT4r5SThDkUJPy-VPY_anVxsKzQ_xK91amKHT6nugHk6Ke9dDTxuTdcf4K59c9ulGn9yEPmHO0w0-4d3yhDlPo_k0TZ5kbqdzl-T_6iaZm2lEj6bLUW6l33uEd8pRbqSxPOIcVfWD3fpN999U1Qf7j5NR) + - [2n-c7gn 200ge c7gn ena dpdk ip6scale20k-rnd](https://csit.fd.io/report/#eNrtV8tqwzAQ_BrnUjZY27jqpYem_o-gStvExFGEpAaSr69iAmuTFhqwmx508IsZs-MdhsEh7j2tArUvRbUs5LJA2Zh0Kh5fH9LFtwEXJcLBOcDFPN15akkFArSg5dqCKMs1CSfIKjDObKFxTyAq8fwOQgPFzfk5HUGrlrDcgrcGrPHnGfh2mXE1kFHzGRlNMgbIgTyDA31Mc5tjj_ODaqYrT4r5SThDkUJPy_efxuwPr3YUmhPxK91amKHT6nugHk6KR9dDLxuTdcf4K59c9ulGn9yEPmHO0w0-4d3yhDlPo_k0TZ5kbqdrl-T_6iaZm2lEj6bLUW6l33uEd8pRbqSxPOIcVfXM7v2u-2-q6i8e_5Mx) +- ipsec + - [3n-icx 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYwlK7Fw-ufQ_D0tldkv4gYN369NK6CW2MiZql9cClP5kBBr58yQRjW43PBquHJNsl-S6huSzdI9k83rqXrgxlKYVOKaDszn1prJAbhE0DUpyBpOkRqSK4Jal4Ad4dQOhe2RZIRrZ7IALQnqRiUhkULLVNZd7A_e-HSWRjgaOh2f1R1NCUeliZPl1W_lKGj5av1kddcbNIh9oHZ1X7NHXqfc63e_H5XCP3Az636KMWzaSen27Yjz9oXqOR7-gnGY_PZwiHaRIU87VtrybRyznmxZixLlMVmV6FqQrMlEZPAzClq3pKo6eLMw3tKYueBmDKVvWURU8XZxrOU1nLc2x7_4p0OL3_1vX-mmiU9CpEAzsaW94AROmajsaGd3GigR2N7W4AomxNR2OzuzhR72hW3DStrse73qz4ALThK64) + - [3n-icx 100ge cx6 dpdk 40tnlsw](https://csit.fd.io/report/#eNrtmEtOwzAQQE8TNmhQ7DqkGxaU3AOlztBa5GNsUxpOjxMqTSqEBKhOWHiTj2Zsj_30pJGt6ww-WqzvkmyT5JuE56ryj2R1f-1fprZcpBwOWgMXN_7LYI2lRVi1oOQRWJrukGuGa5bKF6h09QzS9Np1wDK23gKTgG6vtFDaohSpa2v7Bv5_O8yiWgclWp7d7mQDbWWGpfnDaekvdVC0enUU9dWdRQ5oKHhWNqXpfU8532-GBpQGSxrxuUeKOrSTgn66Yxr_ZMoGrXpHmmQ8P8qQHtQkKM_Xdr2eRE8HmRdjxsJUdaR6Gao6NFUeXQ1BlS_rKo-uzk81uKsiuhqCqljWVRFdnZ9qQFdVo46xBf4z1OH4_l0H_GumUdTLMA3taWx_QzDli3oam9_5mYb2NLa-IZiKRT2Nje_8TMnTrLhqO9OMd8BZ8QHg7TU-) + - [3n-spr 100ge e810cq avf 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYwlK7Fw-79j0MpbO7JP1BwGp9emndhG2MiZql9cClP5kBBr58yQRjO41PBuuHJNsn-T6huazcI9nsbt1L14aylEKvFFB257401sgNwqYtwSgNJE2PSBXBLUnFM_D-AEIPynZAMrItgQhAe5KKSWVQsNS2tXkF91-Os8jWAkdDs_ujaKCt9Lg0fTwv_aUOH61erI-66maRHrUPzsr2aeo0-JzvN-MHcI3cj_jco49aNBcF_XTHfvxB8waNfEc_yXR-PkM4UBdBMV_bDuoiej7IvJgyVqaqItXrUFWhqdLoagiqdF1XaXR1earBXWXR1RBU2bqusujq8lQDuiob-RZb4D9DHY_v33XAv2YaRb0O09CexvY3BFO6qqex-V2eaWhPY-sbgilb1dPY-C7P1HuaFTdtp5vpDjgrPgDqXTZ2) + - [3n-spr 200ge cx7 mlx5 40tnlsw](https://csit.fd.io/report/#eNrtmM1OxCAQgJ-mXsyYlgXrxYNr38OwdNwl6Q8BrK1PL62b0MbEaFzEA5f-ZAYY-PIlE4ztNT4ZbO4zts_KfUZKWbtHtnu4di_dGEJzAoNSQOiN-9LYIDcIu46DURpInh-RqEKM5YDcQtuMDISelO2hYMXdAQoBaE9SUakMCprbrjGv4P4P8zyys8DREHZ7FC10tZ4XJ4_nxT9V4qP1i_VRV98mMqD2wU3hPk2dJp_z1Xb8EK6R-zEfu_RRi2ZV0nf37Mc_a96ikW_oJ1lO0GcIB2sVFNu17aRW0fNRltWSEZ2sSmQvRVaFJ0uSs2HIktjOkuRsDLJ_4CxNzoYhS2M7S5OzMcgGdVa2ckyt8S_Azgf4DzvjH3NNwl6Ka3hfU1schiuJ7GtqimNwDe9raonDcKWRfU0NcQyu3ldWXXW9bpc7Y1a9A6ljU84) +- hoststack quic + - [3n-icx 100ge e810cq dpdk ip4udpquic](https://csit.fd.io/report/#eNrlVctuwyAQ_Br3Um0FxJZz6aGJ_6PCsK1RSExYHDX9-hIr6tpqc80hvgDSzOxrtIJSH_Gd0L8W1aaoN4Wqnc1HsXp7zlf0pEqh4BQCqPIlvyJ61ISwOoAzXyCF-EQVJK6lMEewwe6g6ylR0mYHUq1FC9IApg5cKAcbjoMz7SVADomm66ENdMmnttd8f5IzaofEaNbPkBNGBme1Mi10Z-bc7oAFOqJmxW9jTEhIk5put8mKj6j3SO4bWTaOiRkmWzIBzTxbOocJep1e3YyMO_lHRnvMfC8FLcDH_9p9UD-XZecju7ms5bzzblbN06GP-_HPrJof9LcJqA) + - [3n-icx 100ge cx6 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCYte99NDU_6gw3taoOKYsjpy8PsSKurbaXHNwLoA0M8zujhAU-4AfhO41K7ZZuc1UaZu0ZJu3x7QFRyoXCvbeg8qf0imgQ00Imx1YM4IU4guVl2Z8bkbo3FhA21OkqM03SPUiapAGMLZgfT40_mewpj7r041o2h5qT2c79X6x--PNaDNERpN-gewxMLgolWm-PTDnagPM1wE1C377YkJEmpV0vUtWfAbdIdkjsmyaEjNMCmQGmqVbPPgZehleWU2M26RHRjuUwjgpaP0p_tftOtO8qzBXnOVdPcwbv8uietj1oZv-yqI6ATY_CZg) + - [3n-spr 200ge cx7 mlx5 ip4udpquic](https://csit.fd.io/report/#eNrlVctugzAQ_Bp6qbayHRC99NCE_4iM2RRUExyvQUm-Pg6KsqA-jjmEi21pZvY1WplC53FLaD-SbJ3k60TlTRWPZPX5Gi9vSaVCweAcqPQtvjxa1ISw2msg50EJ8YXKSXPMB9QBWnvMoO4oUNDmG6R6FyVIAxhqaFzaV-7QN6a8hohB0dQdlI6uGdXmlvFHekarPjAa9TNkQM_grFqmufrEnP96YIn2qFlzb40JAWlS1d-NsmLndYvUnJFl46CYYaItE9DMs4WTm6C3-eXFyHiYh2S0RSmMlYIW4eVvDT-tp0uz9LkdXdqSPnhHs-Jl3_l2_EOz4gJZsRPY) +- hoststack tcp udp + - [3n-icx 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbNe99JDU_4gwbGorJKYsiZK-vsSKuraqNKf2EF8AMTPsDiMExT7gitC9ZuUyq5aZqjqbhixfPKYpOFKFUHDwHlTxlFYBHWpCyHfQmSNIId5ReYkvUpgPsN5uoO0pUtRmA7J4Fg1IAxhb6HwRjW_OYmd9OqfXNm1iWOfQeDoXVW-Xoj86YNTuI6OprwlywMDgpGGm-fbEnOs2WKADalZ8u2NCRBr1dMMry9ZBb5G6T2TtcGHMMCmcEWimJePJj9DLFVb1wPiHJMloh9I4KWgugf5m-T5y3dv5vNBrXu8mybm90BuW_z7Xsn7Y9WE7_KVl_QUYjRDu) + - [3n-icx 100ge cx6 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVcFuwyAM_ZrsMnkCkjSnHdblPyYC7hKNNAjTKt3Xj0bVnGjqeuqluQDiPWM_P1lQHAJ-ELrXrNxm1TZTVWfTkuVvz2kLjlQhFBy9B1W8pFNAh5oQ8j10ZgQpxCcqL824sSP0biyhHShS1OYLZLERDUgDGFvofBGNb86xzvr0zKBtusSwy6HxdM6p3i85_xTAqD1ERlNZC-SIgcFFvUzz7Yk5V1UwXwfUHPArjgkRaVbSDakctgu6R-q-kWOnfjHDJGtmoFmmjCc_Qy8drOqJcX8fyWiH0jgpaCV2_qf4IVw92NVM5zWpj-LjyqbzhuL7u1rWT_sh9NMfWtY_O78Q3g) + - [3n-spr 100ge e810cq dpdk ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFOwzAQfE24oEW2kxAuHCj5B3LsLYmaNovXrVRejxtVbCJEe4JDc7Etz4x3xyPLHIeAb4z9c1ausmqVmarzacjyl_s0hZ5NoQwciMAUD2kVsEfLCPmuAaYAWql3NKTxSSv3AZ78BtqBI0frNqCLR9WAdoCxhY6K6Kg5qXtP6aDB-rSJYZ1DQ3yqal7PVX-0IKjfR0FTYzPkgEHAWcdCo_YonAs-RGEDWpF82xNCRJ40dcWsyNbBbpG7TxTteGPCcCmeCejmJeORJuj5Dqt6ZPxHluxsj9r1WvFiIr3k-UaS3fsFvdLfzN5Olot7pVc8_32yZX23G8J2_FPL-gse3xSG) + - [3n-spr 200ge cx7 mlx5 ip4tcp ipudp](https://csit.fd.io/report/#eNrlVUFuwyAQfI17qbYCbNenHpr4HxWGTW0Vx4glVtLXl1hR11bV5NQe4gsgZobdYYSgOAR8I3QvWbnJqk2mqs6mIctfH9MUHKlCKBi9B1U8pVVAh5oQ8r0G8gGUEO-ovDTHakQdoXfHEtqBIkVtPkAWz6IBaQBjC50vovHNWe6sTycN2qZNDLscGk_nsmp7KfujB0btITKaOlsgIwYGFy0zzbcn5lwzwhIdULPm2x8TItKsqxtuWbYLukfqPpG105Uxw6SAZqBZlownP0Mvl1jVE-Nf0iSjHUrjpKD1hHrN9L1ke7Breqm_ub2jNNf3Um-Y_vtsy_phP4R--lvL-gsy1Rse) +- nat44 + - [2n-icx 100ge e810cq avf ethip4tcp tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZIsiT70kNS_0dQ5E1tcJytpJikX185DcimGAotLYRc9JpZ7Y6GRT4cHG48ds-ZWmfFOhNFW8chy1ePcXKdF5IJGIhAyKe4ctih8Qiih9aegDP2ioI4lpzZNzDDDlqS4_EWuAUMTdwGS-PpdoxrOBMSSOfgtVRcQKBjgL52Y1Lxck36pYKE1seQ0FjXDBnQJXBWcKJRc55wlmQkvnFoUkDUkaCAflLMN8Wm8J0ze_TtO6Y7xodLBBvNmWB2njmcaYJen7CoLox_c5LuTv7USfpzJ7VSuf5UJ7koC13edlsu6L2Zzlzyk-5-_mp_quqhP7j95e9U1QekIvTr) + - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVctqwzAQ_Br3UrZYa0n2pYek_o-iypva4DhbSTGkX185DcimGAotLYRc9JqRdmeHRT4cHD176h8ztc3KbYZl18QhKzb3cXK9R5kjjMyA8iGuHPVkPAEO4NmByPNXQhZUidy-gRl30LGcjl9AWKDQxm2wDIMJUlIDrchRAusCvJZKIAQ-BhgaNwXFp0vQLxkktDmGhMa8FshILoGLhBON29OMsyYj8Y0jky5EOQkK5GfJfFNsur5zZk--e6f0xlS4RLDRnBlml5HDiWfopYRlfWb8m5N8c_KnTvKfO6mVKvSnOimwKnV13W25ovdqOnPNT775-av9qeq74eD2579T1R-52PPT) + - [2n-spr 100ge e810cq avf ethip4tcp-nat44ed cps](https://csit.fd.io/report/#eNrtVdtqwzAM_ZrsZWjYju3kZQ_r8h_Fc9QlkKaa7QXar5_XFZSwFQYbG5S--MKRfHR0EI5pF3AdcbgvzKqoVoWq-jYvRflwm7cwRKWFgokIlL7Lp4ADuoigRogUQArxjIok1lL4F3DTBnrSYPUTSA-YunxLnmB0SWtsoZNCaSBbQrTaSAWeIoxteKdUjyfKT_yMtq-J0VzVApkwMLgol8Oo289izongeBfQcUJWw1DCOCvme1o5exPcFmN_QH4id41xn41hSPolb9rTDD01sGqOEf_kIl1d_JmL9NcuWmNK-yFNS1VXtr7ocfxa7oVM5Bkv6erlL86laW7GXdge_0rTvAFXze5j) + - [2n-spr 200ge cx7 mlx5 ethip4tcp-nat44ed tput](https://csit.fd.io/report/#eNrtVdtqwzAM_ZrsZWjYip30ZQ_t8h_Dc7QlkKTCdkPbr6_bFZwwAoMNCqUvvnAk6xwdhH3YOnr31L1mepOVmwzLto5Llq-f4-Y6j0ogjMyA6iWeHHVkPAEO4NkBCvFFyNLuy5FMgL7ba2hZgRTiA6QFCk28BsswmKAU1dBIgQq4yMEXSkuEwLsAQ-3OZfHtWvYHh4TWu5DQyGyGjOQSOKOcwrg5TGKWhaQM48iklCgoQYH8hM4v5ab0T2d68u2R0hvn1qUAGw2aYHZeORx4gl6bWFaXiBu6yQ83_-4m38DNQuu8-NanJK7KYnXv47mg-I4mdMlTfnj6z3Oqq6dh6_rLX6qrEyEm_aM) +- tunnels (gnv, vxlan, gtpu) + - [2n-icx 100ge e810cq avf ethip4udpgeneve](https://csit.fd.io/report/#eNrtVsGKwjAQ_ZruZZmlia3dyx7U_ofEdNRCjWOSFvXrN5XCtCvCHgSh9ZKEvDeZmTweifNHi2uH1U-ULqNsGcmsLMIQzRafYbKVk0ksoSECmXyFlcUKlUOQBkp9BhHHO5Qk8FvE-gSq2UJJydrXxmDlYJ5sQGhAvw-70M11QTs02CCIeSC2AZv2SFPYNrNcdZnvymC0qD2jobgB0qBlcFA102h_6XEe9cJ8ZVFxQK9Fpnh0vaL-1TIHb606oCuvyCeEu2NcB5kYEnqY1l-oh3b3mOU3xms1pbemT9GUXqvp9Gw6dpdOz6Qj96hMp_eYDnseo0__qEpvVZ_t1TT_MEd7uP1_0_wX2pkbKQ) + - [3n-icx 100ge cx6 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlkFuwjAQRU-TbqqpksEhqy4KuQcKzhQiOcayHQicvg5CmkQtCxCFjTdx5P_tGfvpS3Z-Z2nlSH0m-SIpFgkWTR0-yezrPQxWORQpwt4YQPER_iwpqhzBTEMje8jSdENoMtnP6x5a1efQGLHyndakHMzFGjIJ5LdhduNN5w6Dvh520LUdCuHyUuhXVVbrzrMaepkoe7IsTppkm9ke2XO1dfZXlipeMDoRWzy5UVN_nZC937ZqyTUn4gXhZliXAQJLmZxW8UczUi_XVpRnx1OJmUjsHmLm_4lhzNhtxPDVGcOYsUcSe0LGRMzYbcTEqzMmYsYeSYwzlpdvemfb85sxL38A-znb1g) + - [3n-spr 200ge cx7 mlx5 vxlan](https://csit.fd.io/report/#eNrtVcFuwjAM_ZpymTy1oV1PHAb9D5SmHlRKg-WEquzrF1glt0Jw4YCEuCRRnl_s5ycrPhwYtx7tKinWSblOVNk2cUmW3x9xY-tVniroiUDln_HEaFF7hKXT4IlBpekOFWVmKHvUATo7FNBSvg1H59B6-MpryAxg2MfbfrDagVV1U8dHOm0sO3ANnzOqzZjxKr2gzTEIGouaIT2ygLNqJYz2J4m5p0EomlELZyJNQgL6SV23pQrjh3WHvv1FocVGCW6iLQJlZp4rnGiCjv0rq0vEczykt4cPeUjP8XAwZ2EvPoH_Il9q9kbf6O3bw_NWVAt34O7y_xXVH06v_as) + - [3n-spr 200ge cx7 mlx5 gtpu sw](https://csit.fd.io/report/#eNrtlsFugzAMhp-GXSZP4IZx2mEt71Gl4LVIgVpJYO2efqGqZNCmSZ0q1EMuBPH_xk4-_VKcP1raOjJvSb5OinWCRVOHR7J6fw6LNQ5VijAwA6qX8GbJkHYEq06DYwuYpntCzqpTMZD20JpTDg2rre-7joyDV7WDrALyh_B177l3n6O-G3_S1XbshZtrrx-NRa17L2oYZ6YMZEWczSk2PpzF89f0UqItaamZbEosntxkrt82Kd4Pq1tyzRdJQTgc0auAQqSsmnfxZ56o15MryotjaW4cuf2TGy_CDWPebuaGD5A3jHm7M7dl8qZi3m7mph4gbyrm7c7cJG95-dQdbXu5V-blN__K6zY) + - [3n-spr 200ge cx7 mlx5 wireguard](https://csit.fd.io/report/#eNrtVl1rwyAU_TXZy3CoTUhe-rA2_6PYeNcGjJWrSdv9-plQuAmD7WWsUPui4jnX-3E4oA8nhJ0Hs86KTVZuMlm2Oi7Z6v01bmi8zLlkg3NM5m_xhGBAeWArq5h3yCTnB5BONJdyABVYZy4Fa12-C721YDwThaj2TDQMwjHe99qdW4RDr1ALzoM1_jzy9-OjVuOYW25vub8VQqjuA6GxvAUyABK4qJto7nglzk_dUIhCUBQza5IoAfysrt9bpsgPVB349hMofBodMZoo1QxsllnD1c3Q2yTLemLcW1f31PWPdHV31TU5tybg1eSc-vg-rVLzafX4Pq1S82n1zz4t6hd7wm76Bxf1F_3qK2U) +- reassembly + - [3n-icx 100ge e810cq dpdk reassembly](https://csit.fd.io/report/#eNrtVkFOwzAQfE24oEWx65BeOFDyD5Q4S2uROMZrCuH1uKHSJkJckNLmkIttecar2R2NZAqdx2fC5iHJdkm-S2Ru6rgkm8fbuPmGpEolHJ0Dqe7iyWODJSFsLBj9CSJN9yidwK1I9RvUrn4F7XsXOhCZ2FYgNGA4GKeMI9SRngbb0AfEm-pUx9gAJZLM7ve6jdVLImyrpgdb-5MO-XTW8UsUo_V7YDRKnSBH9AxOemCaO_TM-bszflBGofzip2FGA9JI0L_a52IvvmyRzBdyxWGyzNDRwhGop0JC70boeap5MTCW5Ldb_Z7Bbze333LN92X9ltfNt1zzvSS_Z8-3WvN9Wb_VdfOt1nwvyW_Od1bc2M63wz89K74B21hUdQ) + +## CSIT-2402 Selected Performance Comparisons + +Comparisons 24.02 vs 23.10 +- [2n-icx 100ge e810cq avf 1c 64B PDR](https://csit.fd.io/comparisons/#eNqNkE0OwiAQhU9TN4YGsLVuXFh7AGO8AMGpadJSHGijnl7oj9jEhQkBZt43zPAM1CAtXPdRlkc8QygBQUlw92hzWI9ZA3aKL9g56bgekr6yatUCvXYz6o5eax-MvFN6wCBibXhCOeGbmFGC7jVhIOCVKlEEmitSyQdhlN6AawY7RuWdiL4MFbLFz9ipn4UdfZgWk15iY6rXEtkm-YKx9qmXxKk4T0Q2rLlXowX-4ZKjRAP2--PBiBHpRd3BD1-S2O1fvgz9V6rFZu9HS4s34Cl0zQ) + +## CSIT-2402 Selected Performance Coverage Data + +CSIT-2402 VPP v24.02 coverage data +- [2n-icx 200ge cx7 mlx5 ip4](https://csit.fd.io/coverage/#eNpVjsEOwiAQRL8GLwaDK4RTD9r-h9ngxpIgJYBI_94SD9TLJjNvZjOJHJlsFz8wfWOgo0vbZZfr8SdACmgGjM14vHOnJYQ_Uih2CPIkgMftOybqsTCvu4zn1lQOQjwJwtlUXQgzf7mqegMjYa_YIJvQ0yHNy-fuMJM368BU2763WkpNXye-PaE) + +## Further Information + +For further information including instructions how to access the needed +information with user selectable options, please refer to +[csit.fd.io documentation]({{< relref "/" >}}). diff --git a/docs/content/release_notes/previous/csit_rls2402/dpdk_performance.md b/docs/content/release_notes/previous/csit_rls2402/dpdk_performance.md new file mode 100644 index 0000000000..97e757fe50 --- /dev/null +++ b/docs/content/release_notes/previous/csit_rls2402/dpdk_performance.md @@ -0,0 +1,38 @@ +--- +title: "DPDK Performance" +weight: 2 +--- + +# CSIT 24.02 - DPDK Performance + +1. TEST FRAMEWORK + - **CSIT test environment** version has been updated to ver. 14, see + [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). +2. DPDK PERFORMANCE TESTS + - No updates +3. DPDK RELEASE VERSION CHANGE + - Version 23.11 is now tested. + +# Known Issues + +List of known issues in CSIT 24.02 for DPDK performance tests: + +## New + +List of new issues in CSIT 24.02 for DPDK performance tests: + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | + +## Previous + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | + +## Fixed + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | diff --git a/docs/content/release_notes/previous/csit_rls2402/trex_performance.md b/docs/content/release_notes/previous/csit_rls2402/trex_performance.md new file mode 100644 index 0000000000..d0f82fd2e7 --- /dev/null +++ b/docs/content/release_notes/previous/csit_rls2402/trex_performance.md @@ -0,0 +1,40 @@ +--- +title: "TRex Performance" +weight: 3 +--- + +# CSIT 24.02 - TRex Performance + +1. TEST FRAMEWORK + - **CSIT test environment** version has been updated to ver. 14, see + [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). +2. TREX TESTS + - No updates +3. TREX VERSION + - Currently using v3.03 of TRex. + +# Known Issues + +## New + +List of new issues in CSIT 24.02 for TRex performance tests: + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | + +## Previous + +List of known issues in CSIT 24.02 for TRex performance tests + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | + +## Fixed + +List of known issues in CSIT 24.02 for TRex performance tests + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | diff --git a/docs/content/release_notes/previous/csit_rls2402/vpp_device.md b/docs/content/release_notes/previous/csit_rls2402/vpp_device.md new file mode 100644 index 0000000000..3ade1c6b68 --- /dev/null +++ b/docs/content/release_notes/previous/csit_rls2402/vpp_device.md @@ -0,0 +1,27 @@ +--- +title: "VPP Device" +weight: 4 +--- + +# CSIT 24.02 - VPP Device + +1. TEST FRAMEWORK + - **CSIT test environment** version has been updated to ver. 14, see + [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). + +# Known Issues + +List of known issues in CSIT 24.02 for VPP functional tests in VPP Device: + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | [CSIT-1931](https://jira.fd.io/browse/CSIT-1931) | Vhost test not running in device jobs + 2 | [CSIT-1932](https://jira.fd.io/browse/CSIT-1932) | 1n-spr: Occasional packet loss in L2 tests + +## New + +List of new issues in CSIT 24.02 for VPP functional tests in VPP Device: + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | | diff --git a/docs/content/release_notes/previous/csit_rls2402/vpp_performance.md b/docs/content/release_notes/previous/csit_rls2402/vpp_performance.md new file mode 100644 index 0000000000..3b3711039e --- /dev/null +++ b/docs/content/release_notes/previous/csit_rls2402/vpp_performance.md @@ -0,0 +1,108 @@ +--- +title: "VPP Performance" +weight: 1 +--- + +# CSIT 24.02 - VPP Performance + +1. TEST FRAMEWORK + - **CSIT test environment** version has been updated to ver. 14, see + [Environment Versioning]({{< ref "../../../infrastructure/fdio_csit_testbed_versioning" >}}). + - **General Code Housekeeping**: Ongoing code optimizations and bug fixes. + - **Trending and release testing**: Ndrpdr tests use newer code + (MLRsearch 1.2.1) and configuration, gaining more stability and speed. +1. VPP PERFORMANCE TESTS + - Added 2n-c7gn and 3n-icxd testbeds. +2. PRESENTATION AND ANALYTICS LAYER + - [Performance dashboard](https://csit.fd.io/) got updated with the + possibility to [search in tests](https://csit.fd.io/search/). + - [Per Release Performance Comparisons](https://csit.fd.io/comparisons/) got + updated with the function removing extreme outliers from data presented in + the comparison table. + +# Known Issues + +These are issues that cause test failures or otherwise limit usefulness of CSIT +testing. + +## New + +Any issue listed here may have been present also in a previous release, +but was not detected/recognized/reported enough back then. +Also, issues previously thought fixed but now reopened are listed here. + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | [CSIT-1845](https://jira.fd.io/browse/CSIT-1845) | AVF 9000B any ndrpdr test may start failing due to packets not arriving in one or both directions. + 2 | [CSIT-1946](https://jira.fd.io/browse/CSIT-1946) | Ipsec hwasync fails with large scale and multiple queues. + 3 | [CSIT-1947](https://jira.fd.io/browse/CSIT-1947) | VPP crash in udp nat avf 4c tests. + 4 | [CSIT-1948](https://jira.fd.io/browse/CSIT-1948) | NICs do not consistently distribute tunnels over RXQs depending on model or plugin. + 5 | [CSIT-1950](https://jira.fd.io/browse/CSIT-1950) | 9000B tests with high encap overhead see fragmented packets. + 6 | [CSIT-1951](https://jira.fd.io/browse/CSIT-1951) | Combination of AVF and vhost drops all 9000B packets. + 7 | [CSIT-1954](https://jira.fd.io/browse/CSIT-1954) | 3n-icx: 9000B AVF ip6 tests show zero traffic in one direction due to no free tx slots. + +## Previous + +Issues reported in previous releases which still affect the current results. + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | [CSIT-1782](https://jira.fd.io/browse/CSIT-1782) | Multicore AVF tests are failing when trying to create interface. Frequency is reduced by CSIT workaround, but occasional failures do still happen. + 2 | [CSIT-1785](https://jira.fd.io/browse/CSIT-1785) | NAT44ED tests failing to establish all TCP sessions. At least for max scale, in allotted time (limited by session 500s timeout) due to worse slow path performance than previously measured and calibrated for. CSIT removed the max scale NAT tests to avoid this issue. + 3 | [CSIT-1795](https://jira.fd.io/browse/CSIT-1795) | Ocassionally not all DET44 sessions have been established: 4128767 != 4128768 + 4 | [CSIT-1802](https://jira.fd.io/browse/CSIT-1802) | All testbeds: AF-XDP - NDR tests failing from time to time on small loss. + 5 | [CSIT-1804](https://jira.fd.io/browse/CSIT-1804) | 3n-tsh: NDR fails on ierrors. + 6 | [CSIT-1849](https://jira.fd.io/browse/CSIT-1849) | 2n-clx, 2n-icx: UDP 16m TPUT tests fail to create all sessions. + 7 | [CSIT-1881](https://jira.fd.io/browse/CSIT-1881) | 2n-icx: NFV density tests ocassionally breaks VPP which fails to start. + 8 | [CSIT-1886](https://jira.fd.io/browse/CSIT-1886) | 3n-icx: Wireguard tests with 100 and more tunnels are failing PDR criteria. + 9 | [CSIT-1892](https://jira.fd.io/browse/CSIT-1892) | 3n-alt: Unexpected two-band structure of ipsec and vxlan. + 10 | [CSIT-1896](https://jira.fd.io/browse/CSIT-1896) | Depending on topology, l3fwd avoids dut-dut link. + 11 | [CSIT-1901](https://jira.fd.io/browse/CSIT-1901) | 3n-icx: Negative ipackets on TB38 AVF 4c l2patch. + 12 | [CSIT-1904](https://jira.fd.io/browse/CSIT-1904) | DPDK 23.03 testpmd startup fails on some testbeds. + 13 | [CSIT-1906](https://jira.fd.io/browse/CSIT-1906) | Zero traffic with cx7 rdma. Testing migrated to mlx5-core on all Mellanox NICs. + 14 | [VPP-2077](https://jira.fd.io/browse/VPP-2077) | IP fragmentation: running_fragment_id is not thread safe. Causes reduced performance and failures in gtpu reassembly tests. + 15 | [CSIT-1914](https://jira.fd.io/browse/CSIT-1914) | TRex does not produce latency data on ICE NICs. + 16 | [CSIT-1915](https://jira.fd.io/browse/CSIT-1915) | The 2n-icx testbeds to not have the same performance. + 17 | [CSIT-1916](https://jira.fd.io/browse/CSIT-1916) | Poor CPU scaling on 2n-zn2 RDMA. + 18 | [CSIT-1917](https://jira.fd.io/browse/CSIT-1917) | TRex STL performance is unstable at high pps due to unsent packets. + 19 | [CSIT-1921](https://jira.fd.io/browse/CSIT-1921) | Two-band structure in SRv6, causes PDR failure in rare cases. + 20 | [CSIT-1922](https://jira.fd.io/browse/CSIT-1922) | 2n-tx2: AF_XDP MRR failures. On other testbeds MRR regressions and PDR failures. + 21 | [CSIT-1924](https://jira.fd.io/browse/CSIT-1924) | An l3fwd error in 200Ge2P1Cx7Veat-Mlx5 test with 9000B. + 22 | [CSIT-1935](https://jira.fd.io/browse/CSIT-1935) | Zero traffic reported in udpquic tests due to session close errors. + 23 | [CSIT-1936](https://jira.fd.io/browse/CSIT-1936) | TRex occasionally sees link down in L2 perf tests. + 24 | [CSIT-1937](https://jira.fd.io/browse/CSIT-1937) | Small but frequent loss in ASTF UDP on cx7 mlx5. + 25 | [CSIT-1938](https://jira.fd.io/browse/CSIT-1938) | 3n-alt: High scale ipsec policy tests may crash VPP. + 26 | [CSIT-1939](https://jira.fd.io/browse/CSIT-1939) | 3na-spr, 2n-zn2: VPP fails to start in first test cases. + 27 | [CSIT-1941](https://jira.fd.io/browse/CSIT-1941) | TRex may wrongly detect link bandwidth. + 28 | [CSIT-1942](https://jira.fd.io/browse/CSIT-1942) | 3nb-spr hoststack: Interface not up after first test. + 29 | [CSIT-1943](https://jira.fd.io/browse/CSIT-1943) | IMIX 4c tests may fail PDR due to ~10% loss. + 30 | [CSIT-1944](https://jira.fd.io/browse/CSIT-1944) | Memif LXC: unrecognized option '--no-validate'. + 31 | [VPP-2090](https://jira.fd.io/browse/VPP-2090) | MRR < PDR: DPDK plugin with MLX5 driver does not read full queue. + 32 | [VPP-2091](https://jira.fd.io/browse/VPP-2091) | Memif crashes with jumbo frames. + +## Fixed + +Issues reported in previous releases which were fixed in this release: + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | [CSIT-1883](https://jira.fd.io/browse/CSIT-1883) | 3n-snr: All hwasync wireguard tests failing when trying to verify device. + 2 | [CSIT-1940](https://jira.fd.io/browse/CSIT-1940) | Hardware acceleration does not work yet. + 3 | [VPP-2087](https://jira.fd.io/browse/VPP-2087) | VPP crash and other symptoms in tests with AVF, jumbo packets. + 4 | [VPP-2088](https://jira.fd.io/browse/VPP-2088) | virtio: Bad CLI argument parsing introduced with tx-queue-size. + +# Root Cause Analysis for Regressions + +List of RCAs in CSIT 24.02 for VPP performance regressions. +Not listing differences caused by known issues (uneven worker load +due to randomized RSS or other per-worker issues). +Also not listing tests which historically show large performance variance. + +Contrary to issues, these genuine regressions do not limit usefulness +of CSIT testing. So even if they are not fixed +(e.g. when the regression is an expected consequence of added functionality), +they will not be re-listed in the next release report. + +**#** | **JiraID** | **Issue Description** +------|--------------------------------------------------|-------------------------------------------------------------- + 1 | [VPP-2099](https://jira.fd.io/browse/VPP-2099) | Bump of rdma-core to 49.0 decreased performance. diff --git a/docs/data/variables.yaml b/docs/data/variables.yaml index 0f69d8cdd7..c4f1f03863 100644 --- a/docs/data/variables.yaml +++ b/docs/data/variables.yaml @@ -1,2 +1,3 @@ -release_csit: "CSIT 24.02" -release_vpp: "VPP 24.02"
\ No newline at end of file +release_csit: "CSIT 24.06" +release_vpp: "VPP 24.06" +dashboard_url: "https://csit.fd.io/"
\ No newline at end of file diff --git a/docs/ietf/draft-ietf-bmwg-mlrsearch-06.md b/docs/ietf/draft-ietf-bmwg-mlrsearch-06.md deleted file mode 100644 index 27d65e2690..0000000000 --- a/docs/ietf/draft-ietf-bmwg-mlrsearch-06.md +++ /dev/null @@ -1,1634 +0,0 @@ ---- - -title: Multiple Loss Ratio Search -abbrev: MLRsearch -docname: draft-ietf-bmwg-mlrsearch-06 -date: 2024-03-04 - -ipr: trust200902 -area: ops -wg: Benchmarking Working Group -kw: Internet-Draft -cat: info - -coding: us-ascii -pi: # can use array (if all yes) or hash here - toc: yes - sortrefs: # defaults to yes - symrefs: yes - -author: - - - ins: M. Konstantynowicz - name: Maciek Konstantynowicz - org: Cisco Systems - email: mkonstan@cisco.com - - - ins: V. Polak - name: Vratko Polak - org: Cisco Systems - email: vrpolak@cisco.com - -normative: - RFC1242: - RFC2285: - RFC2544: - RFC9004: - -informative: - TST009: - target: https://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/009/03.04.01_60/gs_NFV-TST009v030401p.pdf - title: "TST 009" - FDio-CSIT-MLRsearch: - target: https://csit.fd.io/cdocs/methodology/measurements/data_plane_throughput/mlr_search/ - title: "FD.io CSIT Test Methodology - MLRsearch" - date: 2023-10 - PyPI-MLRsearch: - target: https://pypi.org/project/MLRsearch/1.2.1/ - title: "MLRsearch 1.2.1, Python Package Index" - date: 2023-10 - ---- abstract - -This document proposes extensions to [RFC2544] throughput search by -defining a new methodology called Multiple Loss Ratio search -(MLRsearch). MLRsearch aims to minimize search duration, -support multiple loss ratio searches, -and enhance result repeatability and comparability. - -The primary reason for extending [RFC2544] is to address the challenges -and requirements presented by the evaluation and testing -of software-based networking systems' data planes. - -To give users more freedom, MLRsearch provides additional configuration options -such as allowing multiple shorter trials per load instead of one large trial, -tolerating a certain percentage of trial results with higher loss, -and supporting the search for multiple goals with varying loss ratios. - ---- middle - -{::comment} - As we use Kramdown to convert from Markdown, - we use this way of marking comments not to be visible in the rendered draft. - https://stackoverflow.com/a/42323390 - If another engine is used, convert to this way: - https://stackoverflow.com/a/20885980 -{:/comment} - -# Purpose and Scope - -The purpose of this document is to describe Multiple Loss Ratio search -(MLRsearch), a data plane throughput search methodology optimized for software -networking DUTs. - -Applying vanilla [RFC2544] throughput bisection to software DUTs -results in several problems: - -- Binary search takes too long as most trials are done far from the - eventually found throughput. -- The required final trial duration and pauses between trials - prolong the overall search duration. -- Software DUTs show noisy trial results, - leading to a big spread of possible discovered throughput values. -- Throughput requires a loss of exactly zero frames, but the industry - frequently allows for small but non-zero losses. -- The definition of throughput is not clear when trial results are inconsistent. - - -To address the problems mentioned above, -the MLRsearch library employs the following enhancements: - -- Allow multiple shorter trials instead of one big trial per load. - - Optionally, tolerate a percentage of trial results with higher loss. -- Allow searching for multiple search goals, with differing loss ratios. - - Any trial result can affect each search goal in principle. -- Insert multiple coarse targets for each search goal, earlier ones need - to spend less time on trials. - - Earlier targets also aim for lesser precision. - - Use Forwarding Rate (FR) at maximum offered load - [RFC2285] (section 3.6.2) to initialize the initial targets. -- Take care when dealing with inconsistent trial results. - - Reported throughput is smaller than the smallest load with high loss. - - Smaller load candidates are measured first. -- Apply several load selection heuristics to save even more time - by trying hard to avoid unnecessarily narrow bounds. - -Some of these enhancements are formalized as MLRsearch specification, -the remaining enhancements are treated as implementation details, -thus achieving high comparability without limiting future improvements. - -MLRsearch configuration options are flexible enough to -support both conservative settings and aggressive settings. -Where the conservative settings lead to results -unconditionally compliant with [RFC2544], -but longer search duration and worse repeatability. -Conversely, aggressive settings lead to shorter search duration -and better repeatability, but the results are not compliant with [RFC2544]. - -No part of [RFC2544] is intended to be obsoleted by this document. - -# Identified Problems - -This chapter describes the problems affecting usability -of various performance testing methodologies, -mainly a binary search for [RFC2544] unconditionally compliant throughput. - -## Long Search Duration - -The emergence of software DUTs, with frequent software updates and a -number of different frame processing modes and configurations, -has increased both the number of performance tests -required to verify the DUT update and the frequency of running those tests. -This makes the overall test execution time even more important than before. - -The current [RFC2544] throughput definition restricts the potential -for time-efficiency improvements. -A more generalized throughput concept could enable further enhancements -while maintaining the precision of simpler methods. - -The bisection method, when unconditionally compliant with [RFC2544], -is excessively slow. -This is because a significant amount of time is spent on trials -with loads that, in retrospect, are far from the final determined throughput. - -[RFC2544] does not specify any stopping condition for throughput search, -so users already have an access to a limited trade-off -between search duration and achieved precision. -However, each full 60-second trials doubles the precision, -so not many trials can be removed without a substantial loss of precision. - -## DUT in SUT - -[RFC2285] defines: -- DUT as - - The network forwarding device to which stimulus is offered and - response measured [RFC2285] (section 3.1.1). -- SUT as - - The collective set of network devices to which stimulus is offered - as a single entity and response measured [RFC2285] (section 3.1.2). - -[RFC2544] specifies a test setup with an external tester stimulating the -networking system, treating it either as a single DUT, or as a system -of devices, an SUT. - -In the case of software networking, the SUT consists of not only the DUT -as a software program processing frames, but also of -a server hardware and operating system functions, -with server hardware resources shared across all programs -and the operating system running on the same server. - -Given that the SUT is a shared multi-tenant environment -encompassing the DUT and other components, the DUT might inadvertently -experience interference from the operating system -or other software operating on the same server. - -Some of this interference can be mitigated. -For instance, -pinning DUT program threads to specific CPU cores -and isolating those cores can prevent context switching. - -Despite taking all feasible precautions, some adverse effects may still impact -the DUT's network performance. -In this document, these effects are collectively -referred to as SUT noise, even if the effects are not as unpredictable -as what other engineering disciplines call noise. - -DUT can also exhibit fluctuating performance itself, for reasons -not related to the rest of SUT; for example due to pauses in execution -as needed for internal stateful processing. -In many cases this -may be an expected per-design behavior, as it would be observable even -in a hypothetical scenario where all sources of SUT noise are eliminated. -Such behavior affects trial results in a way similar to SUT noise. -As the two phenomenons are hard to distinguish, -in this document the term 'noise' is used to encompass -both the internal performance fluctuations of the DUT -and the genuine noise of the SUT. - -A simple model of SUT performance consists of an idealized noiseless performance, -and additional noise effects. -For a specific SUT, the noiseless performance is assumed to be constant, -with all observed performance variations being attributed to noise. -The impact of the noise can vary in time, sometimes wildly, -even within a single trial. -The noise can sometimes be negligible, but frequently -it lowers the observed SUT performance as observed in trial results. - -In this model, SUT does not have a single performance value, it has a spectrum. -One end of the spectrum is the idealized noiseless performance value, -the other end can be called a noiseful performance. -In practice, trial result -close to the noiseful end of the spectrum happens only rarely. -The worse the performance value is, the more rarely it is seen in a trial. -Therefore, the extreme noiseful end of the SUT spectrum is not observable -among trial results. -Also, the extreme noiseless end of the SUT spectrum -is unlikely to be observable, this time because some small noise effects -are likely to occur multiple times during a trial. - -Unless specified otherwise, this document's focus is -on the potentially observable ends of the SUT performance spectrum, -as opposed to the extreme ones. - -When focusing on the DUT, the benchmarking effort should ideally aim -to eliminate only the SUT noise from SUT measurements. -However, -this is currently not feasible in practice, as there are no realistic enough -models available to distinguish SUT noise from DUT fluctuations, -based on the author's experience and available literature. - -Assuming a well-constructed SUT, the DUT is likely its -primary performance bottleneck. -In this case, we can define the DUT's -ideal noiseless performance as the noiseless end of the SUT performance spectrum, -especially for throughput. -However, other performance metrics, such as latency, -may require additional considerations. - -Note that by this definition, DUT noiseless performance -also minimizes the impact of DUT fluctuations, as much as realistically possible -for a given trial duration. - -This document aims to solve the DUT in SUT problem -by estimating the noiseless end of the SUT performance spectrum -using a limited number of trial results. - -Any improvements to the throughput search algorithm, aimed at better -dealing with software networking SUT and DUT setup, should employ -strategies recognizing the presence of SUT noise, allowing the discovery of -(proxies for) DUT noiseless performance -at different levels of sensitivity to SUT noise. - -## Repeatability and Comparability - -[RFC2544] does not suggest to repeat throughput search. -And from just one -discovered throughput value, it cannot be determined how repeatable that value is. -Poor repeatability then leads to poor comparability, -as different benchmarking teams may obtain varying throughput values -for the same SUT, exceeding the expected differences from search precision. - -[RFC2544] throughput requirements (60 seconds trial and -no tolerance of a single frame loss) affect the throughput results -in the following way. -The SUT behavior close to the noiseful end of its performance spectrum -consists of rare occasions of significantly low performance, -but the long trial duration makes those occasions not so rare on the trial level. -Therefore, the binary search results tend to wander away from the noiseless end -of SUT performance spectrum, more frequently and more widely than shorter -trials would, thus causing poor throughput repeatability. - -The repeatability problem can be addressed by defining a search procedure -that identifies a consistent level of performance, -even if it does not meet the strict definition of throughput in [RFC2544]. - -According to the SUT performance spectrum model, better repeatability -will be at the noiseless end of the spectrum. -Therefore, solutions to the DUT in SUT problem -will help also with the repeatability problem. - -Conversely, any alteration to [RFC2544] throughput search -that improves repeatability should be considered -as less dependent on the SUT noise. - -An alternative option is to simply run a search multiple times, and report some -statistics (e.g. average and standard deviation). -This can be used -for a subset of tests deemed more important, -but it makes the search duration problem even more pronounced. - -## Throughput with Non-Zero Loss - -[RFC1242] (section 3.17) defines throughput as: - The maximum rate at which none of the offered frames - are dropped by the device. - -Then, it says: - Since even the loss of one frame in a - data stream can cause significant delays while - waiting for the higher level protocols to time out, - it is useful to know the actual maximum data - rate that the device can support. - -However, many benchmarking teams accept a small, -non-zero loss ratio as the goal for their load search. - -Motivations are many: - -- Modern protocols tolerate frame loss better, - compared to the time when [RFC1242] and [RFC2544] were specified. - -- Trials nowadays send way more frames within the same duration, - increasing the chance of a small SUT performance fluctuation - being enough to cause frame loss. - -- Small bursts of frame loss caused by noise have otherwise smaller impact - on the average frame loss ratio observed in the trial, - as during other parts of the same trial the SUT may work more closely - to its noiseless performance, thus perhaps lowering the trial loss ratio - below the goal loss ratio value. - -- If an approximation of the SUT noise impact on the trial loss ratio is known, - it can be set as the goal loss ratio. - -Regardless of the validity of all similar motivations, -support for non-zero loss goals makes any search algorithm more user-friendly. -[RFC2544] throughput is not user-friendly in this regard. - -Furthermore, allowing users to specify multiple loss ratio values, -and enabling a single search to find all relevant bounds, -significantly enhances the usefulness of the search algorithm. - -Searching for multiple search goals also helps to describe the SUT performance -spectrum better than the result of a single search goal. -For example, the repeated wide gap between zero and non-zero loss loads -indicates the noise has a large impact on the observed performance, -which is not evident from a single goal load search procedure result. - -It is easy to modify the vanilla bisection to find a lower bound -for the intended load that satisfies a non-zero goal loss ratio. -But it is not that obvious how to search for multiple goals at once, -hence the support for multiple search goals remains a problem. - -## Inconsistent Trial Results - -While performing throughput search by executing a sequence of -measurement trials, there is a risk of encountering inconsistencies -between trial results. - -The plain bisection never encounters inconsistent trials. -But [RFC2544] hints about the possibility of inconsistent trial results, -in two places in its text. -The first place is section 24, where full trial durations are required, -presumably because they can be inconsistent with the results -from shorter trial durations. -The second place is section 26.3, where two successive zero-loss trials -are recommended, presumably because after one zero-loss trial -there can be a subsequent inconsistent non-zero-loss trial. - -Examples include: - -- A trial at the same load (same or different trial duration) results - in a different trial loss ratio. -- A trial at a higher load (same or different trial duration) results - in a smaller trial loss ratio. - -Any robust throughput search algorithm needs to decide how to continue -the search in the presence of such inconsistencies. -Definitions of throughput in [RFC1242] and [RFC2544] are not specific enough -to imply a unique way of handling such inconsistencies. - -Ideally, there will be a definition of a new quantity which both generalizes -throughput for non-zero-loss (and other possible repeatability enhancements), -while being precise enough to force a specific way to resolve trial result -inconsistencies. -But until such a definition is agreed upon, the correct way to handle -inconsistent trial results remains an open problem. - -# MLRsearch Specification - -This chapter focuses on technical definitions needed for evaluating -whether a particular test procedure adheres to MLRsearch specification. - -For motivations, explanations, and other comments see other chapters. - -## MLRsearch Architecture - -MLRsearch architecture consists of three main components: -the manager, the controller, and the measurer. -For definitions of the components, see the following sections. - -The architecture also implies the presence of other components, such as the SUT. - -These components can be seen as abstractions present in any testing procedure. - -### Measurer - -The measurer is the component that performs one trial -as described in [RFC2544] section 23. - -Specifically, one call to the measurer accepts a trial load value -and trial duration value, performs the trial, and returns -the measured trial loss ratio, and optionally a different duration value. - -It is the responsibility of the measurer to uphold any requirements -and assumptions present in MLRsearch specification -(e.g. trial forwarding ratio not being larger than one). -Implementers have some freedom, for example in the way they deal with -duplicated frames, or what to return if the tester sent zero frames towards SUT. -Implementations are RECOMMENDED to document their behavior -related to such freedoms in as detailed a way as possible. - -Implementations MUST document any deviations from RFC documents, -for example if the wait time around traffic -is shorter than what [RFC2544] section 23 specifies. - -### Controller - -The controller selects trial load and duration values -to achieve the search goals in the shortest expected time. - -The controller calls the measurer multiple times, -receiving the trial result from each call. -After exit condition is met, the controller returns -the overall search results. - -The controller's role in optimizing trial load and duration selection -distinguishes MLRsearch algorithms from simpler search procedures. - -For controller inputs, see later section Controller Inputs. -For controller outputs, see later section Controller Outputs. - -### Manager - -The controller gets initiated by the manager once, and subsequently calls - -The manager is the component that initializes SUT, the traffic generator -(tester in [RFC2544] terminology), the measurer and the controller -with intended configurations. -It then calls the controller once, and receives its outputs. - -The manager is also responsible for creating reports in the appropriate format, -based on information in controller outputs. - -## Units - -The specification deals with physical quantities, so it is assumed -each numeric value is accompanied by an appropriate physical unit. - -The specification does not state which unit is appropriate, -but implementations MUST make it explicit which unit is used -for each value provided or received by the user. - -For example, load quantities (including the conditional throughput) -returned by the controller are defined to be based on a single-interface -(unidirectional) loads. -For bidirectional traffic, users are likely -to expect bidirectional throughput quantities, so the manager is responsible -for making its report clear. - -## SUT - -As defined in [RFC2285]: -The collective set of network devices to which stimulus is offered -as a single entity and response measured. - -## Trial - -A trial is the part of the test described in [RFC2544] section 23. - -### Trial Load - -The trial load is the intended constant load for a trial. - -Load is the quantity implied by Constant Load of [RFC1242], -Data Rate of [RFC2544] and Intended Load of [RFC2285]. -All three specify this value applies to one (input or output) interface. - -### Trial Duration - -Trial duration is the intended duration of the traffic for a trial. - -In general, this quantity does not include any preparation nor waiting -described in section 23 of [RFC2544]. - -However, the measurer MAY return a duration value that deviates -from the intended duration. -This feature can be beneficial for users -who wish to manage the overall search duration, -rather than solely the traffic portion of it. -The manager MUST report -how the measurer computes the returned duration values in that case. - -### Trial Forwarding Ratio - -The trial forwarding ratio is a dimensionless floating point value -that ranges from 0.0 to 1.0, inclusive. -It is calculated by dividing the number of frames -successfully forwarded by the SUT -by the total number of frames expected to be forwarded during the trial. - -Note that, contrary to loads, frame counts used to compute -trial forwarding ratio are aggregates over all SUT output ports. - -Questions around what is the correct number of frames -that should have been forwarded is outside of the scope of this document. -E.g. what should the measurer return when it detects -that the offered load differs significantly from the intended load. - -### Trial Loss Ratio - -The trial loss ratio is equal to one minus the trial forwarding ratio. - -### Trial Forwarding Rate - -The trial forwarding rate is a derived quantity, calculated by -multiplying the trial load by the trial forwarding ratio. - -It is important to note that while similar, this quantity is not identical -to the Forwarding Rate as defined in [RFC2285] section 3.6.1, -as the latter is specific to one output interface, -whereas the trial forwarding ratio is based -on frame counts aggregated over all SUT output interfaces. - -## Traffic profile - -Any other specifics (besides trial load and trial duration) -the measurer needs in order to perform the trial -are understood as a composite called the traffic profile. -All its attributes are assumed to be constant during the search, -and the composite is configured on the measurer by the manager -before the search starts. - -The traffic profile is REQUIRED by [RFC2544] -to contain some specific quantities, for example frame size. -Several more specific quantities may be RECOMMENDED. - -Depending on SUT configuration, e.g. when testing specific protocols, -additional values need to be included in the traffic profile -and in the test report. -See other IETF documents. - -## Search Goal - -The search goal is a composite consisting of several attributes, -some of them are required. -Implementations are free to add their own attributes. - -A particular set of attribute values is called a search goal instance. - -Subsections list all required attributes and one recommended attribute. -Each subsection contains a short informal description, -but see other chapters for more in-depth explanations. - -The meaning of the attributes is formally given only by their effect -on the controller output attributes (defined in later in section Search Result). - -Informally, later chapters give additional intuitions and examples -to the search goal attribute values. -Later chapters also give motivation to formulas of computation of the outputs. - -### Goal Final Trial Duration - -A threshold value for trial durations. -This attribute is REQUIRED, and the value MUST be positive. - -Informally, while MLRsearch is allowed to perform trials shorter than this, -but results from such short trials have only limited impact on search results. - -The full relation needs definitions is later subsections. -But for example, the conditional throughput -(definition in subsection Conditional Throughput) -for this goal will be computed only from trial results -from trials at least as long as this. - -### Goal Duration Sum - -A threshold value for a particular sum of trial durations. -This attribute is REQUIRED, and the value MUST be positive. - -This uses the duration values returned by the measurer. - -Informally, even when looking only at trials done at this goal's -final trial duration, MLRsearch may spend up to this time measuring -the same load value. -If the goal duration sum is larger than -the goal final trial duration, it means multiple trials need to be measured -at the same load. - -### Goal Loss Ratio - -A threshold value for trial loss ratios. -REQUIRED attribute, MUST be non-negative and smaller than one. - -Informally, if a load causes too many trials with trial loss ratios -larger than this, the conditional throughput for this goal -will be smaller than that load. - -### Goal Exceed Ratio - -A threshold value for a particular ratio of duration sums. -REQUIRED attribute, MUST be non-negative and smaller than one. - -The duration sum values come from the duration values returned by the measurer. - -Informally, the impact of lossy trials is controlled by this value. -The full relation needs definitions is later subsections. - -But for example, the definition of the conditional throughput -(given later in subsection Conditional Throughput) -refers to a q-value for a quantile when selecting -which trial result gives the conditional throughput. -The goal exceed ratio acts as the q-value to use there. - -Specifically, when the goal exceed ratio is 0.5 and MLRsearch happened -to use the whole goal duration sum (using full-length trials), -it means the conditional throughput is the median of trial forwarding rates. - -### Goal Width - -A value used as a threshold for telling when two trial load values -are close enough. - -RECOMMENDED attribute, positive. -Implementations without this attribute -MUST give the manager other ways to control the search exit condition. - -Absolute load difference and relative load difference are two popular choices, -but implementations may choose a different way to specify width. - -Informally, this acts as a stopping condition, controlling the precision -of the search. -The search stops if every goal has reached its precision. - -## Controller Inputs - -The only REQUIRED input for controller is a set of search goal instances. -MLRsearch implementations MAY use additional input parameters for the controller. - -The order of instances SHOULD NOT have a big impact on controller outputs, -but MLRsearch implementations MAY base their behavior on the order -of search goal instances. - -The search goal instances SHOULD NOT be identical. -MLRsearch implementation MAY allow identical instances. - -## Goal Result - -Before defining the output of the controller, -it is useful to define what the goal result is. - -The goal result is a composite object consisting of several attributes. -A particular set of attribute values is called a goal result instance. - -Any goal result instance can be either regular or irregular. -MLRsearch specification puts requirements on regular goal result instances. -Any instance that does not meet the requirements is deemed irregular. - -Implementations are free to define their own irregular goal results, -but the manager MUST report them clearly as not regular according to this section. - -All attribute values in one goal result instance -are related to a single search goal instance, -referred to as the given search goal. - -Some of the attributes of a regular goal result instance are required, -some are recommended, implementations are free to add their own. - -The subsections define two required and one optional attribute -for a regular goal result. - -A typical irregular result is when all trials at the maximal offered load -have zero loss, as the relevant upper bound does not exist in that case. - -### Relevant Upper Bound - -The relevant upper bound is the smallest intended load value that is classified -at the end of the search as an upper bound (see Appendix A) -for the given search goal. -This is a REQUIRED attribute. - -Informally, this is the smallest intended load that failed to uphold -all the requirements of the given search goal, mainly the goal loss ratio -in combination with the goal exceed ratio. - -### Relevant Lower Bound - -The relevant lower bound is the largest intended load value -among those smaller than the relevant upper bound -that got classified at the end of the search -as a lower bound (see Appendix A) for the given search goal. -This is a REQUIRED attribute. - -For a regular goal result, the distance between the relevant lower bound -and the relevant upper bound MUST NOT be larger than the goal width, -if the implementation offers width as a goal attribute. - -Informally, this is the largest intended load that managed to uphold -all the requirements of the given search goal, mainly the goal loss ratio -in combination with the goal exceed ratio, while not being larger -than the relevant upper bound. - -### Conditional Throughput - -The conditional throughput (see Appendix B) -as evaluated at the relevant lower bound of the given search goal -at the end of the search. -This is a RECOMMENDED attribute. - -Informally, this is a typical forwarding rate expected to be seen -at the relevant lower bound of the given search goal. -But frequently just a conservative estimate thereof, -as MLRsearch implementations tend to stop gathering more data -as soon as they confirm the result cannot get worse than this estimate -within the goal duration sum. - -## Search Result - -The search result is a single composite object -that maps each search goal to a corresponding goal result. - -In other words, search result is an unordered list of key-value pairs, -where no two pairs contain equal keys. -The key is a search goal instance, acting as the given search goal -for the goal result instance in the value portion of the key-value pair. - -The search result (as a mapping) -MUST map from all the search goals present in the controller input. - -## Controller Outputs - -The search result is the only REQUIRED output -returned from the controller to the manager. - -MLRsearch implementation MAY return additional data in the controller output. - -# Further Explanations - -This chapter focuses on intuitions and motivations -and skips over some important details. - -Familiarity with the MLRsearch specification is not required here, -so this chapter can act as an introduction. -For example, this chapter starts talking about the tightest lower bounds -before it is ready to talk about the relevant lower bound from the specification. - -## MLRsearch Versions - -The MLRsearch algorithm has been developed in a code-first approach, -a Python library has been created, debugged, and used in production -before the first descriptions (even informal) were published. -In fact, multiple versions of the library were used in the production -over the past few years, and later code was usually not compatible -with earlier descriptions. - -The code in (any version of) MLRsearch library fully determines -the search process (for given configuration parameters), -leaving no space for deviations. -MLRsearch, as a name for a broad class of possible algorithms, -leaves plenty of space for future improvements, at the cost -of poor comparability of results of different MLRsearch implementations. - -There are two competing needs. -There is the need for standardization in areas critical to comparability. -There is also the need to allow flexibility for implementations -to innovate and improve in other areas. -This document defines the MLRsearch specification -in a manner that aims to fairly balances both needs. - -## Exit Condition - -[RFC2544] prescribes that after performing one trial at a specific offered load, -the next offered load should be larger or smaller, based on frame loss. - -The usual implementation uses binary search. -Here a lossy trial becomes -a new upper bound, a lossless trial becomes a new lower bound. -The span of values between (including both) the tightest lower bound -and the tightest upper bound forms an interval of possible results, -and after each trial the width of that interval halves. - -Usually the binary search implementation tracks only the two tightest bounds, -simply calling them bounds. -But the old values still B remain valid bounds, -just not as tight as the new ones. - -After some number of trials, the tightest lower bound becomes the throughput. -[RFC2544] does not specify when (if ever) should the search stop. - -MLRsearch library introduces a concept of goal width. -The search stops -when the distance between the tightest upper bound and the tightest lower bound -is smaller than a user-configured value, called goal width from now on. -In other words, the interval width at the end of the search -has to be no larger than the goal width. - -This goal width value therefore determines the precision of the result. -As MLRsearch specification requires a particular structure of the result, -the result itself does contain enough information to determine its precision, -thus it is not required to report the goal width value. - -This allows MLRsearch implementations to use exit conditions -different from goal width. - -## Load Classification - -MLRsearch keeps the basic logic of binary search (tracking tightest bounds, -measuring at the middle), perhaps with minor technical clarifications. -The algorithm chooses an intended load (as opposed to the offered load), -the interval between bounds does not need to be split -exactly into two equal halves, -and the final reported structure specifies both bounds. - -The biggest difference is that to classify a load -as an upper or lower bound, MLRsearch may need more than one trial -(depending on configuration options) to be performed at the same intended load. - -As a consequence, even if a load already does have few trial results, -it still may be classified as undecided, neither a lower bound nor an upper bound. - -An explanation of the classification logic is given in the next chapter, -as it relies heavily on other sections of this chapter. - -For repeatability and comparability reasons, it is important that -given a set of trial results, all implementations of MLRsearch -classify the load equivalently. - -## Loss Ratios - -The next difference is in the goals of the search. -[RFC2544] has a single goal, -based on classifying full-length trials as either lossless or lossy. - -As the name suggests, MLRsearch can search for multiple goals, -differing in their loss ratios. -The precise definition of the goal loss ratio will be given later. -The [RFC2544] throughput goal then simply becomes a zero goal loss ratio. -Different goals also may have different goal widths. - -A set of trial results for one specific intended load value -can classify the load as an upper bound for some goals, but a lower bound -for some other goals, and undecided for the rest of the goals. - -Therefore, the load classification depends not only on trial results, -but also on the goal. -The overall search procedure becomes more complicated -(compared to binary search with a single goal), -but most of the complications do not affect the final result, -except for one phenomenon, loss inversion. - -## Loss Inversion - -In [RFC2544] throughput search using bisection, any load with a lossy trial -becomes a hard upper bound, meaning every subsequent trial has a smaller -intended load. - -But in MLRsearch, a load that is classified as an upper bound for one goal -may still be a lower bound for another goal, and due to the other goal -MLRsearch will probably perform trials at even higher loads. -What to do when all such higher load trials happen to have zero loss? -Does it mean the earlier upper bound was not real? -Does it mean the later lossless trials are not considered a lower bound? -Surely we do not want to have an upper bound at a load smaller than a lower bound. - -MLRsearch is conservative in these situations. -The upper bound is considered real, and the lossless trials at higher loads -are considered to be a coincidence, at least when computing the final result. - -This is formalized using new notions, the relevant upper bound and -the relevant lower bound. -Load classification is still based just on the set of trial results -at a given intended load (trials at other loads are ignored), -making it possible to have a lower load classified as an upper bound, -and a higher load classified as a lower bound (for the same goal). -The relevant upper bound (for a goal) is the smallest load classified -as an upper bound. -But the relevant lower bound is not simply -the largest among lower bounds. -It is the largest load among loads -that are lower bounds while also being smaller than the relevant upper bound. - -With these definitions, the relevant lower bound is always smaller -than the relevant upper bound (if both exist), and the two relevant bounds -are used analogously as the two tightest bounds in the binary search. -When they are less than the goal width apart, -the relevant bounds are used in the output. - -One consequence is that every trial result can have an impact on the search result. -That means if your SUT (or your traffic generator) needs a warmup, -be sure to warm it up before starting the search. - -## Exceed Ratio - -The idea of performing multiple trials at the same load comes from -a model where some trial results (those with high loss) are affected -by infrequent effects, causing poor repeatability of [RFC2544] throughput results. -See the discussion about noiseful and noiseless ends -of the SUT performance spectrum. -Stable results are closer to the noiseless end of the SUT performance spectrum, -so MLRsearch may need to allow some frequency of high-loss trials -to ignore the rare but big effects near the noiseful end. - -MLRsearch can do such trial result filtering, but it needs -a configuration option to tell it how frequent can the infrequent big loss be. -This option is called the exceed ratio. -It tells MLRsearch what ratio of trials -(more exactly what ratio of trial seconds) can have a trial loss ratio -larger than the goal loss ratio and still be classified as a lower bound. -Zero exceed ratio means all trials have to have a trial loss ratio -equal to or smaller than the goal loss ratio. - -For explainability reasons, the RECOMMENDED value for exceed ratio is 0.5, -as it simplifies some later concepts by relating them to the concept of median. - -## Duration Sum - -When more than one trial is needed to classify a load, -MLRsearch also needs something that controls the number of trials needed. -Therefore, each goal also has an attribute called duration sum. - -The meaning of a goal duration sum is that when a load has trials -(at full trial duration, details later) -whose trial durations when summed up give a value at least this long, -the load is guaranteed to be classified as an upper bound or a lower bound -for the goal. - -As the duration sum has a big impact on the overall search duration, -and [RFC2544] prescribes wait intervals around trial traffic, -the MLRsearch algorithm is allowed to sum durations that are different -from the actual trial traffic durations. - -## Short Trials - -MLRsearch requires each goal to specify its final trial duration. -Full-length trial is a shorter name for a trial whose intended trial duration -is equal to (or longer than) the goal final trial duration. - -Section 24 of [RFC2544] already anticipates possible time savings -when short trials (shorter than full-length trials) are used. -Full-length trials are the opposite of short trials, -so they may also be called long trials. - -Any MLRsearch implementation may include its own configuration options -which control when and how MLRsearch chooses to use shorter trial durations. - -For explainability reasons, when exceed ratio of 0.5 is used, -it is recommended for the goal duration sum to be an odd multiple -of the full trial durations, so conditional throughput becomes identical to -a median of a particular set of forwarding rates. - -The presence of shorter trial results complicates the load classification logic. -Full details are given later. -In short, results from short trials -may cause a load to be classified as an upper bound. -This may cause loss inversion, and thus lower the relevant lower bound -(below what would classification say when considering full-length trials only). - -For explainability reasons, it is RECOMMENDED users use such configurations -that guarantee all trials have the same length. -Alas, such configurations are usually not compliant with [RFC2544] requirements, -or not time-saving enough. - -## Conditional Throughput - -As testing equipment takes the intended load as an input parameter -for a trial measurement, any load search algorithm needs to deal -with intended load values internally. - -But in the presence of goals with a non-zero loss ratio, the intended load -usually does not match the user's intuition of what a throughput is. -The forwarding rate (as defined in [RFC2285] section 3.6.1) is better, -but it is not obvious how to generalize it -for loads with multiple trial results and a non-zero goal loss ratio. - -MLRsearch defines one such generalization, called the conditional throughput. -It is the forwarding rate from one of the trials performed at the load -in question. -Specification of which trial exactly is quite technical, -see the specification and Appendix B. - -Conditional throughput is partially related to load classification. -If a load is classified as a lower bound for a goal, -the conditional throughput can be calculated, -and guaranteed to show an effective loss ratio -no larger than the goal loss ratio. - -While the conditional throughput gives more intuitive-looking values -than the relevant lower bound, especially for non-zero goal loss ratio values, -the actual definition is more complicated than the definition of the relevant -lower bound. -In the future, other intuitive values may become popular, -but they are unlikely to supersede the definition of the relevant lower bound -as the most fitting value for comparability purposes, -therefore the relevant lower bound remains a required attribute -of the goal result structure, while the conditional throughput is only optional. - -Note that comparing the best and worst case, the same relevant lower bound value -may result in the conditional throughput differing up to the goal loss ratio. -Therefore it is rarely needed to set the goal width (if expressed -as the relative difference of loads) below the goal loss ratio. -In other words, setting the goal width below the goal loss ratio -may cause the conditional throughput for a larger loss ratio to become smaller -than a conditional throughput for a goal with a smaller goal loss ratio, -which is counter-intuitive, considering they come from the same search. -Therefore it is RECOMMENDED to set the goal width to a value no smaller -than the goal loss ratio. - -## Search Time - -MLRsearch was primarily developed to reduce the time -required to determine a throughput, either the [RFC2544] compliant one, -or some generalization thereof. -The art of achieving short search times -is mainly in the smart selection of intended loads (and intended durations) -for the next trial to perform. - -While there is an indirect impact of the load selection on the reported values, -in practice such impact tends to be small, -even for SUTs with quite a broad performance spectrum. - -A typical example of two approaches to load selection leading to different -relevant lower bounds is when the interval is split in a very uneven way. -Any implementation choosing loads very close to the current relevant lower bound -is quite likely to eventually stumble upon a trial result -with poor performance (due to SUT noise). -For an implementation choosing loads very close -to the current relevant upper bound, this is unlikely, -as it examines more loads that can see a performance -close to the noiseless end of the SUT performance spectrum. - -However, as even splits optimize search duration at give precision, -MLRsearch implementations that prioritize minimizing search time -are unlikely to suffer from any such bias. - -Therefore, this document remains quite vague on load selection -and other optimization details, and configuration attributes related to them. -Assuming users prefer libraries that achieve short overall search time, -the definition of the relevant lower bound -should be strict enough to ensure result repeatability -and comparability between different implementations, -while not restricting future implementations much. - -Sadly, different implementations may exhibit their sweet spot of -the best repeatability for a given search duration -at different goals attribute values, especially concerning -any optional goal attributes such as the initial trial duration. -Thus, this document does not comment much on which configurations -are good for comparability between different implementations. -For comparability between different SUTs using the same implementation, -refer to configurations recommended by that particular implementation. - -## [RFC2544] compliance - -The following search goal ensures unconditional compliance with -[RFC2544] throughput search procedure: - -- Goal loss ratio: zero. - -- Goal final trial duration: 60 seconds. - -- Goal duration sum: 60 seconds. - -- Goal exceed ratio: zero. - -The presence of other search goals does not affect the compliance -of this goal result. -The relevant lower bound and the conditional throughput are in this case -equal to each other, and the value is the [RFC2544] throughput. - -If the 60 second quantity is replaced by a smaller quantity in both attributes, -the conditional throughput is still conditionally compliant with -[RFC2544] throughput. - -# Logic of Load Classification - -This chapter continues with explanations, -but this time more precise definitions are needed -for readers to follow the explanations. -The definitions here are wordy, implementers should read the specification -chapter and appendices for more concise definitions. - -The two related areas of focus in this chapter are load classification -and the conditional throughput, starting with the latter. - -The section Performance Spectrum contains definitions -needed to gain insight into what conditional throughput means. -The rest of the subsections discuss load classification, -they do not refer to Performance Spectrum, only to a few duration sums. - -For load classification, it is useful to define good and bad trials. -A trial is called bad (according to a goal) if its trial loss ratio -is larger than the goal loss ratio. -The trial that is not bad is called good. - -## Performance Spectrum - -There are several equivalent ways to explain -the conditional throughput computation. -One of the ways relies on an object called the performance spectrum. -First, two heavy definitions are needed. - -Take an intended load value, a trial duration value, and a finite set -of trial results, all trials measured at that load value and duration value. -The performance spectrum is the function that maps -any non-negative real number into a sum of trial durations among all trials -in the set that has that number as their forwarding rate, -e.g. map to zero if no trial has that particular forwarding rate. - -A related function, defined if there is at least one trial in the set, -is the performance spectrum divided by the sum of the durations -of all trials in the set. -That function is called the performance probability function, as it satisfies -all the requirements for probability mass function function -of a discrete probability distribution, -the one-dimensional random variable being the trial forwarding rate. - -These functions are related to the SUT performance spectrum, -as sampled by the trials in the set. - -As for any other probability function, we can talk about percentiles -of the performance probability function, including the median. -The conditional throughput will be one such quantile value -for a specifically chosen set of trials. - -Take a set of all full-length trials performed at the relevant lower bound, -sorted by decreasing forwarding rate. -The sum of the durations of those trials -may be less than the goal duration sum, or not. -If it is less, add an imaginary trial result with zero forwarding rate, -such that the new sum of durations is equal to the goal duration sum. -This is the set of trials to use. -The q-value for the quantile -is the goal exceed ratio. -If the quantile touches two trials, -the larger forwarding rate (from the trial result sorted earlier) is used. -The resulting quantity is the conditional throughput of the goal in question. - -First example. -For zero exceed ratio, when goal duration sum has been reached. -The conditional throughput is the smallest forwarding rate among the trials. - -Second example. -For zero exceed ratio, when goal duration sum has not been reached yet. -Due to the missing duration sum, the worst case may still happen, -so the conditional throughput is zero. -This is not reported to the user, -as this load cannot become the relevant lower bound yet. - -Third example. -Exceed ratio 50%, goal duration sum two seconds, -one trial present with the duration of one second and zero loss. -The imaginary trial is added with the duration -of one second and zero forwarding rate. -The median would touch both trials, so the conditional throughput -is the forwarding rate of the one non-imaginary trial. -As that had zero loss, the value is equal to the offered load. - -Note that Appendix B does not take into account short trial results. - -### Summary - -While the conditional throughput is a generalization of the forwarding rate, -its definition is not an obvious one. - -Other than the forwarding rate, the other source of intuition -is the quantile in general, and the median the the recommended case. - -In future, different quantities may prove more useful, -especially when applying to specific problems, -but currently the conditional throughput is the recommended compromise, -especially for repeatability and comparability reasons. - -## Single Trial Duration - -When goal attributes are chosen in such a way that every trial has the same -intended duration, the load classification is simpler. - -The following description looks technical, but it follows the motivation -of goal loss ratio, goal exceed ratio, and goal duration sum. -If the sum of the durations of all trials (at the given load) -is less than the goal duration sum, imagine best case scenario -(all subsequent trials having zero loss) and worst case scenario -(all subsequent trials having 100% loss). -Here we assume there are as many subsequent trials as needed -to make the sum of all trials equal to the goal duration sum. -As the exceed ratio is defined just using sums of durations -(number of trials does not matter), it does not matter whether -the "subsequent trials" can consist of an integer number of full-length trials. - -In any of the two scenarios, we can compute the load exceed ratio, -As the duration sum of good trials divided by the duration sum of all trials, -in both cases including the assumed trials. - -If even in the best case scenario the load exceed ratio would be larger -than the goal exceed ratio, the load is an upper bound. -If even in the worst case scenario the load exceed ratio would not be larger -than the goal exceed ratio, the load is a lower bound. - -Even more specifically. -Take all trials measured at a given load. -The sum of the durations of all bad full-length trials is called the bad sum. -The sum of the durations of all good full-length trials is called the good sum. -The result of adding the bad sum plus the good sum is called the measured sum. -The larger of the measured sum and the goal duration sum is called the whole sum. -The whole sum minus the measured sum is called the missing sum. -The optimistic exceed ratio is the bad sum divided by the whole sum. -The pessimistic exceed ratio is the bad sum plus the missing sum, -that divided by the whole sum. -If the optimistic exceed ratio is larger than the goal exceed ratio, -the load is classified as an upper bound. -If the pessimistic exceed ratio is not larger than the goal exceed ratio, -the load is classified as a lower bound. -Else, the load is classified as undecided. - -The definition of pessimistic exceed ratio is compatible with the logic in -the conditional throughput computation, so in this single trial duration case, -a load is a lower bound if and only if the conditional throughput -effective loss ratio is not larger than the goal loss ratio. -If it is larger, the load is either an upper bound or undecided. - -## Short Trial Scenarios - -Trials with intended duration smaller than the goal final trial duration -are called short trials. -The motivation for load classification logic in the presence of short trials -is based around a counter-factual case: What would the trial result be -if a short trial has been measured as a full-length trial instead? - -There are three main scenarios where human intuition guides -the intended behavior of load classification. - -False good scenario. -The user had their reason for not configuring a shorter goal -final trial duration. -Perhaps SUT has buffers that may get full at longer -trial durations. -Perhaps SUT shows periodic decreases in performance -the user does not want to be treated as noise. -In any case, many good short trials may become bad full-length trials -in the counter-factual case. -In extreme cases, there are plenty of good short trials and no bad short trials. -In this scenario, we want the load classification NOT to classify the load -as a lower bound, despite the abundance of good short trials. -Effectively, we want the good short trials to be ignored, so they -do not contribute to comparisons with the goal duration sum. - -True bad scenario. -When there is a frame loss in a short trial, -the counter-factual full-length trial is expected to lose at least as many -frames. -And in practice, bad short trials are rarely turning into -good full-length trials. -In extreme cases, there are no good short trials. -In this scenario, we want the load classification -to classify the load as an upper bound just based on the abundance -of short bad trials. -Effectively, we want the bad short trials -to contribute to comparisons with the goal duration sum, -so the load can be classified sooner. - -Balanced scenario. -Some SUTs are quite indifferent to trial duration. -Performance probability function constructed from short trial results -is likely to be similar to the performance probability function constructed -from full-length trial results (perhaps with larger dispersion, -but without a big impact on the median quantiles overall). -For a moderate goal exceed ratio value, this may mean there are both -good short trials and bad short trials. -This scenario is there just to invalidate a simple heuristic -of always ignoring good short trials and never ignoring bad short trials. -That simple heuristic would be too biased. -Yes, the short bad trials -are likely to turn into full-length bad trials in the counter-factual case, -but there is no information on what would the good short trials turn into. -The only way to decide safely is to do more trials at full length, -the same as in scenario one. - -## Short Trial Logic - -MLRsearch picks a particular logic for load classification -in the presence of short trials, but it is still RECOMMENDED -to use configurations that imply no short trials, -so the possible inefficiencies in that logic -do not affect the result, and the result has better explainability. - -With that said, the logic differs from the single trial duration case -only in different definition of the bad sum. -The good sum is still the sum across all good full-length trials. - -Few more notions are needed for defining the new bad sum. -The sum of durations of all bad full-length trials is called the bad long sum. -The sum of durations of all bad short trials is called the bad short sum. -The sum of durations of all good short trials is called the good short sum. -One minus the goal exceed ratio is called the inceed ratio. -The goal exceed ratio divided by the inceed ratio is called the exceed coefficient. -The good short sum multiplied by the exceed coefficient is called the balancing sum. -The bad short sum minus the balancing sum is called the excess sum. -If the excess sum is negative, the bad sum is equal to the bad long sum. -Otherwise, the bad sum is equal to the bad long sum plus the excess sum. - -Here is how the new definition of the bad sum fares in the three scenarios, -where the load is close to what would the relevant bounds be -if only full-length trials were used for the search. - -False good scenario. -If the duration is too short, we expect to see a higher frequency -of good short trials. -This could lead to a negative excess sum, -which has no impact, hence the load classification is given just by -full-length trials. -Thus, MLRsearch using too short trials has no detrimental effect -on result comparability in this scenario. -But also using short trials does not help with overall search duration, -probably making it worse. - -True bad cenario. -Settings with a small exceed ratio -have a small exceed coefficient, so the impact of the good short sum is small, -and the bad short sum is almost wholly converted into excess sum, -thus bad short trials have almost as big an impact as full-length bad trials. -The same conclusion applies to moderate exceed ratio values -when the good short sum is small. -Thus, short trials can cause a load to get classified as an upper bound earlier, -bringing time savings (while not affecting comparability). - -Balanced scenario. -Here excess sum is small in absolute value, as the balancing sum -is expected to be similar to the bad short sum. -Once again, full-length trials are needed for final load classification; -but usage of short trials probably means MLRsearch needed -a shorter overall search time before selecting this load for measurement, -thus bringing time savings (while not affecting comparability). - -Note that in presence of short trial results, -the comparibility between the load classification -and the conditional throughput is only partial. -The conditional throughput still comes from a good long trial, -but a load higher than the relevant lower bound may also compute to a good value. - -## Longer Trial Durations - -If there are trial results with an intended duration larger -than the goal trial duration, the precise definitions -in Appendix A and Appendix B treat them in exactly the same way -as trials with duration equal to the goal trial duration. - -But in configurations with moderate (including 0.5) or small -goal exceed ratio and small goal loss ratio (especially zero), -bad trials with longer than goal durations may bias the search -towards the lower load values, as the noiseful end of the spectrum -gets a larger probability of causing the loss within the longer trials. - -For some users, this is an acceptable price -for increased configuration flexibility -(perhaps saving time for the related goals), -so implementations SHOULD allow such configurations. -Still, users are encouraged to avoid such configurations -by making all goals use the same final trial duration, -so their results remain comparable across implementations. - -# Addressed Problems - -Now when MLRsearch is clearly specified and explained, -it is possible to summarize how does MLRsearch specification help with problems. - -Here, "multiple trials" is a shorthand for having the goal final trial duration -significantly smaller than the goal duration sum. -This results in MLRsearch performing multiple trials at the same load, -which may not be the case with other configurations. - -## Long Test Duration - -As shortening the overall search duration is the main motivation -of MLRsearch library development, the library implements -multiple improvements on this front, both big and small. - -Most of implementation details are not constrained by the MLRsearch specification, -so that future implementations may keep shortening the search duration even more. - -One exception is the impact of short trial results on the relevant lower bound. -While motivated by human intuition, the logic is not straightforward. -In practice, configurations with only one common trial duration value -are capable of achieving good overal search time and result repeatability -without the need to consider short trials. - -### Impact of goal attribute values - -From the required goal attributes, the goal duration sum -remains the best way to get even shorter searches. - -Usage of multiple trials can also save time, -depending on wait times around trial traffic. - -The farther the goal exceed ratio is from 0.5 (towards zero or one), -the less predictable the overal search duration becomes in practice. - -Width parameter does not change search duration much in practice -(compared to other, mainly optional goal attributes). - -## DUT in SUT - -In practice, using multiple trials and moderate exceed ratios -often improves result repeatability without increasing the overall search time, -depending on the specific SUT and DUT characteristics. -Benefits for separating SUT noise are less clear though, -as it is not easy to distinguish SUT noise from DUT instability in general. - -Conditional throughput has an intuitive meaning when described -using the performance spectrum, so this is an improvement -over existing simple (less configurable) search procedures. - -Multiple trials can save time also when the noisy end of -the preformance spectrum needs to be examined, e.g. for [RFC9004]. - -Under some circumstances, testing the same DUT and SUT setup with different -DUT configurations can give some hints on what part of noise is SUT noise -and what part is DUT performance fluctuations. -In practice, both types of noise tend to be too complicated for that analysis. - -MLRsearch enables users to search for multiple goals, -potentially providing more insight at the cost of a longer overall search time. -However, for a thorough and reliable examination of DUT-SUT interactions, -it is necessary to employ additional methods beyond black-box benchmarking, -such as collecting and analyzing DUT and SUT telemetry. - -## Repeatability and Comparability - -Multiple trials improve repeatability, depending on exceed ratio. - -In practice, one-second goal final trial duration with exceed ratio 0.5 -is good enough for modern SUTs. -However, unless smaller wait times around the traffic part of the trial -are allowed, too much of overal search time would be wasted on waiting. - -It is not clear whether exceed ratios higher than 0.5 are better -for repeatability. -The 0.5 value is still preferred due to explainability using median. - -It is possible that the conditional throughput values (with non-zero goal -loss ratio) are better for repeatability than the relevant lower bound values. -This is especially for implementations -which pick load from a small set of discrete values, -as that hides small variances in relevant lower bound values -other implementations may find. - -Implementations focusing on shortening the overall search time -are automatically forced to avoid comparability issues due to load selection, -as they must prefer even splits wherever possible. -But this conclusion only holds when the same goals are used. -Larger adoption is needed before any further claims on comparability -between MLRsearch implementations can be made. - -## Throughput with Non-Zero Loss - -Trivially suported by the goal loss ratio attribute. - -In practice, usage of non-zero loss ratio values -improves the result repeatability -(exactly as expected based on results from simpler search methods). - -## Inconsistent Trial Results - -MLRsearch is conservative wherever possible. -This is built into the definition of conditional throughput, -and into the treatment of short trial results for load classification. - -This is consistent with [RFC2544] zero loss tolerance motivation. - -If the noiseless part of the SUT performance spectrum is of interest, -it should be enough to set small value for the goal final trial duration, -and perhaps also a large value for the goal exceed ratio. - -Implementations may offer other (optional) configuration attributes -to become less conservative, but currently it is not clear -what impact would that have on repeatability. - -# IANA Considerations - -No requests of IANA. - -# Security Considerations - -Benchmarking activities as described in this memo are limited to -technology characterization of a DUT/SUT using controlled stimuli in a -laboratory environment, with dedicated address space and the constraints -specified in the sections above. - -The benchmarking network topology will be an independent test setup and -MUST NOT be connected to devices that may forward the test traffic into -a production network or misroute traffic to the test management network. - -Further, benchmarking is performed on a "black-box" basis, relying -solely on measurements observable external to the DUT/SUT. - -Special capabilities SHOULD NOT exist in the DUT/SUT specifically for -benchmarking purposes. Any implications for network security arising -from the DUT/SUT SHOULD be identical in the lab and in production -networks. - -# Acknowledgements - -Some phrases and statements in this document were created -with help of Mistral AI (mistral.ai). - -Many thanks to Alec Hothan of the OPNFV NFVbench project for thorough -review and numerous useful comments and suggestions. - -Special wholehearted gratitude and thanks to the late Al Morton for his -thorough reviews filled with very specific feedback and constructive -guidelines. Thank you Al for the close collaboration over the years, -for your continuous unwavering encouragement full of empathy and -positive attitude. -Al, you are dearly missed. - -# Appendix A: Load Classification - -This is the specification of how to perform the load classification. - -Any intended load value can be classified, according to the given search goal. - -The algorithm uses (some subsets of) the set of all available trial results -from trials measured at a given intended load at the end of the search. -All durations are those returned by the measurer. - -The block at the end of this appendix holds pseudocode -which computes two values, stored in variables named optimistic and pessimistic. -The pseudocode happens to be a valid Python code. - -If both values are computed to be true, the load in question -is classified as a lower bound according to the given search goal. -If both values are false, the load is classified as an upper bound. -Otherwise, the load is classified as undecided. - -The pseudocode expects the following variables to hold values as follows: - -- goal_duration_sum: The duration sum value of the given search goal. - -- goal_exceed_ratio: The exceed ratio value of the given search goal. - -- good_long_sum: Sum of durations across trials with trial duration - at least equal to the goal final trial duration and with a trial loss ratio - not higher than the goal loss ratio. - -- bad_long_sum: Sum of durations across trials with trial duration - at least equal to the goal final trial duration and with a trial loss ratio - higher than the goal loss ratio. - -- good_short_sum: Sum of durations across trials with trial duration - shorter than the goal final trial duration and with a trial loss ratio - not higher than the goal loss ratio. - -- bad_short_sum: Sum of durations across trials with trial duration - shorter than the goal final trial duration and with a trial loss ratio - higher than the goal loss ratio. - -The code works correctly also when there are no trial results at the given load. - -~~~ python -balancing_sum = good_short_sum * goal_exceed_ratio / (1.0 - goal_exceed_ratio) -effective_bad_sum = bad_long_sum + max(0.0, bad_short_sum - balancing_sum) -effective_whole_sum = max(good_long_sum + effective_bad_sum, goal_duration_sum) -quantile_duration_sum = effective_whole_sum * goal_exceed_ratio -optimistic = effective_bad_sum <= quantile_duration_sum -pessimistic = (effective_whole_sum - good_long_sum) <= quantile_duration_sum -~~~ - -# Appendix B: Conditional Throughput - -This is the specification of how to compute conditional throughput. - -Any intended load value can be used as the basis for the following computation, -but only the relevant lower bound (at the end of the search) -leads to the value called the conditional throughput for a given search goal. - -The algorithm uses (some subsets of) the set of all available trial results -from trials measured at a given intended load at the end of the search. -All durations are those returned by the measurer. - -The block at the end of this appendix holds pseudocode -which computes a value stored as variable conditional_throughput. -The pseudocode happens to be a valid Python code. - -The pseudocode expects the following variables to hold values as follows: - -- goal_duration_sum: The duration sum value of the given search goal. - -- goal_exceed_ratio: The exceed ratio value of the given search goal. - -- good_long_sum: Sum of durations across trials with trial duration - at least equal to the goal final trial duration and with a trial loss ratio - not higher than the goal loss ratio. - -- bad_long_sum: Sum of durations across trials with trial duration - at least equal to the goal final trial duration and with a trial loss ratio - higher than the goal loss ratio. - -- long_trials: An iterable of all trial results from trials with trial duration - at least equal to the goal final trial duration, - sorted by increasing the trial loss ratio. - A trial result is a composite with the following two attributes available: - - - trial.loss_ratio: The trial loss ratio as measured for this trial. - - - trial.duration: The trial duration of this trial. - -The code works correctly only when there if there is at least one -trial result measured at a given load. - -~~~ python -all_long_sum = max(goal_duration_sum, good_long_sum + bad_long_sum) -remaining = all_long_sum * (1.0 - goal_exceed_ratio) -quantile_loss_ratio = None -for trial in long_trials: - if quantile_loss_ratio is None or remaining > 0.0: - quantile_loss_ratio = trial.loss_ratio - remaining -= trial.duration - else: - break -else: - if remaining > 0.0: - quantile_loss_ratio = 1.0 -conditional_throughput = intended_load * (1.0 - quantile_loss_ratio) -~~~ - ---- back diff --git a/docs/ietf/draft-ietf-bmwg-mlrsearch-08.md b/docs/ietf/draft-ietf-bmwg-mlrsearch-08.md new file mode 100644 index 0000000000..387ff4dba8 --- /dev/null +++ b/docs/ietf/draft-ietf-bmwg-mlrsearch-08.md @@ -0,0 +1,3123 @@ +--- + +title: Multiple Loss Ratio Search +abbrev: MLRsearch +docname: draft-ietf-bmwg-mlrsearch-08 +date: 2024-08-28 + +ipr: trust200902 +area: ops +wg: Benchmarking Working Group +kw: Internet-Draft +cat: info + +coding: us-ascii +pi: # can use array (if all yes) or hash here + toc: yes + sortrefs: # defaults to yes + symrefs: yes + +author: + - + ins: M. Konstantynowicz + name: Maciek Konstantynowicz + org: Cisco Systems + email: mkonstan@cisco.com + - + ins: V. Polak + name: Vratko Polak + org: Cisco Systems + email: vrpolak@cisco.com + +normative: + RFC1242: + RFC2285: + RFC2544: + RFC8219: + RFC9004: + +informative: + TST009: + target: https://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/009/03.04.01_60/gs_NFV-TST009v030401p.pdf + title: "TST 009" + FDio-CSIT-MLRsearch: + target: https://csit.fd.io/cdocs/methodology/measurements/data_plane_throughput/mlr_search/ + title: "FD.io CSIT Test Methodology - MLRsearch" + date: 2023-10 + PyPI-MLRsearch: + target: https://pypi.org/project/MLRsearch/1.2.1/ + title: "MLRsearch 1.2.1, Python Package Index" + date: 2023-10 + +--- abstract + +This document proposes extensions to [RFC2544] throughput search by +defining a new methodology called Multiple Loss Ratio search +(MLRsearch). MLRsearch aims to minimize search duration, +support multiple loss ratio searches, +and enhance result repeatability and comparability. + +The primary reason for extending [RFC2544] is to address the challenges +and requirements presented by the evaluation and testing +of software-based networking systems' data planes. + +To give users more freedom, MLRsearch provides additional configuration options +such as allowing multiple short trials per load instead of one large trial, +tolerating a certain percentage of trial results with higher loss, +and supporting the search for multiple goals with varying loss ratios. + +--- middle + +{::comment} + + As we use Kramdown to convert from Markdown, + we use this way of marking comments not to be visible in the rendered draft. + https://stackoverflow.com/a/42323390 + If another engine is used, convert to this way: + https://stackoverflow.com/a/20885980 + + [toc] + +{:/comment} + + +# Purpose and Scope + +The purpose of this document is to describe Multiple Loss Ratio search +(MLRsearch), a data plane throughput search methodology optimized for software +networking DUTs. + +Applying vanilla [RFC2544] throughput bisection to software DUTs +results in several problems: + +- Binary search takes too long as most trials are done far from the + eventually found throughput. +- The required final trial duration and pauses between trials + prolong the overall search duration. +- Software DUTs show noisy trial results, + leading to a big spread of possible discovered throughput values. +- Throughput requires a loss of exactly zero frames, but the industry + frequently allows for small but non-zero losses. +- The definition of throughput is not clear when trial results are inconsistent. + +To address the problems mentioned above, +the MLRsearch test methodology specification employs the following enhancements: + +- Allow multiple short trials instead of one big trial per load. + - Optionally, tolerate a percentage of trial results with higher loss. +- Allow searching for multiple Search Goals, with differing loss ratios. + - Any trial result can affect each Search Goal in principle. +- Insert multiple coarse targets for each Search Goal, earlier ones need + to spend less time on trials. + - Earlier targets also aim for lesser precision. + - Use Forwarding Rate (FR) at maximum offered load + [RFC2285] (section 3.6.2) to initialize the initial targets. +- Take care when dealing with inconsistent trial results. + - Reported throughput is smaller than the smallest load with high loss. + - Smaller load candidates are measured first. +- Apply several load selection heuristics to save even more time + by trying hard to avoid unnecessarily narrow bounds. + +Some of these enhancements are formalized as MLRsearch specification, +the remaining enhancements are treated as implementation details, +thus achieving high comparability without limiting future improvements. + +MLRsearch configuration options are flexible enough to +support both conservative settings and aggressive settings. +The conservative settings lead to results +unconditionally compliant with [RFC2544], +but longer search duration and worse repeatability. +Conversely, aggressive settings lead to shorter search duration +and better repeatability, but the results are not compliant with [RFC2544]. + +No part of [RFC2544] is intended to be obsoleted by this document. + +# Identified Problems + +This chapter describes the problems affecting usability +of various performance testing methodologies, +mainly a binary search for [RFC2544] unconditionally compliant throughput. + +## Long Search Duration + +{::comment} + [Low priority] + + <mark>MKP2 [VP] TODO: Look for mentions of search duration in existing RFCs.</mark> + + <mark>MKP2 [VP] TODO: If not found, define right after defining "the search".</mark> + +{:/comment} + +The emergence of software DUTs, with frequent software updates and a +number of different frame processing modes and configurations, +has increased both the number of performance tests +required to verify the DUT update and the frequency of running those tests. +This makes the overall test execution time even more important than before. + +The current [RFC2544] throughput definition restricts the potential +for time-efficiency improvements. +A more generalized throughput concept could enable further enhancements +while maintaining the precision of simpler methods. + +The bisection method, when unconditionally compliant with [RFC2544], +is excessively slow. +This is because a significant amount of time is spent on trials +with loads that, in retrospect, are far from the final determined throughput. + +[RFC2544] does not specify any stopping condition for throughput search, +so users already have an access to a limited trade-off +between search duration and achieved precision. +However, each full 60-second trials doubles the precision, +so not many trials can be removed without a substantial loss of precision. + +## DUT in SUT + +[RFC2285] defines: +- DUT as + - The network forwarding device to which stimulus is offered and + response measured [RFC2285] (section 3.1.1). +- SUT as + - The collective set of network devices to which stimulus is offered + as a single entity and response measured [RFC2285] (section 3.1.2). + +[RFC2544] specifies a test setup with an external tester stimulating the +networking system, treating it either as a single DUT, or as a system +of devices, an SUT. + +In the case of software networking, the SUT consists of not only the DUT +as a software program processing frames, but also of +server hardware and operating system functions, +with that server hardware resources shared across all programs including +the operating system. + +Given that the SUT is a shared multi-tenant environment +encompassing the DUT and other components, the DUT might inadvertently +experience interference from the operating system +or other software operating on the same server. + +Some of this interference can be mitigated. +For instance, +pinning DUT program threads to specific CPU cores +and isolating those cores can prevent context switching. + +Despite taking all feasible precautions, some adverse effects may still impact +the DUT's network performance. +In this document, these effects are collectively +referred to as SUT noise, even if the effects are not as unpredictable +as what other engineering disciplines call noise. + +DUT can also exhibit fluctuating performance itself, for reasons +not related to the rest of SUT. For example due to pauses in execution +as needed for internal stateful processing. +In many cases this +may be an expected per-design behavior, as it would be observable even +in a hypothetical scenario where all sources of SUT noise are eliminated. +Such behavior affects trial results in a way similar to SUT noise. +As the two phenomenons are hard to distinguish, +in this document the term 'noise' is used to encompass +both the internal performance fluctuations of the DUT +and the genuine noise of the SUT. + +A simple model of SUT performance consists of an idealized noiseless performance, +and additional noise effects. +For a specific SUT, the noiseless performance is assumed to be constant, +with all observed performance variations being attributed to noise. +The impact of the noise can vary in time, sometimes wildly, +even within a single trial. +The noise can sometimes be negligible, but frequently +it lowers the observed SUT performance as observed in trial results. + +In this model, SUT does not have a single performance value, it has a spectrum. +One end of the spectrum is the idealized noiseless performance value, +the other end can be called a noiseful performance. +In practice, trial result +close to the noiseful end of the spectrum happens only rarely. +The worse the performance value is, the more rarely it is seen in a trial. +Therefore, the extreme noiseful end of the SUT spectrum is not observable +among trial results. +Also, the extreme noiseless end of the SUT spectrum +is unlikely to be observable, this time because some small noise effects +are likely to occur multiple times during a trial. + +Unless specified otherwise, this document's focus is +on the potentially observable ends of the SUT performance spectrum, +as opposed to the extreme ones. + +When focusing on the DUT, the benchmarking effort should ideally aim +to eliminate only the SUT noise from SUT measurements. +However, +this is currently not feasible in practice, as there are no realistic enough +models available to distinguish SUT noise from DUT fluctuations, +based on authors' experience and available literature. + +Assuming a well-constructed SUT, the DUT is likely its +primary performance bottleneck. +In this case, we can define the DUT's +ideal noiseless performance as the noiseless end of the SUT performance spectrum, +especially for throughput. +However, other performance metrics, such as latency, +may require additional considerations. + +Note that by this definition, DUT noiseless performance +also minimizes the impact of DUT fluctuations, as much as realistically possible +for a given trial duration. + +MLRsearch methodology aims to solve the DUT in SUT problem +by estimating the noiseless end of the SUT performance spectrum +using a limited number of trial results. + +Any improvements to the throughput search algorithm, aimed at better +dealing with software networking SUT and DUT setup, should employ +strategies recognizing the presence of SUT noise, allowing the discovery of +(proxies for) DUT noiseless performance +at different levels of sensitivity to SUT noise. + +## Repeatability and Comparability + +[RFC2544] does not suggest to repeat throughput search. +And from just one +discovered throughput value, it cannot be determined how repeatable that value is. +Poor repeatability then leads to poor comparability, +as different benchmarking teams may obtain varying throughput values +for the same SUT, exceeding the expected differences from search precision. + +[RFC2544] throughput requirements (60 seconds trial and +no tolerance of a single frame loss) affect the throughput results +in the following way. +The SUT behavior close to the noiseful end of its performance spectrum +consists of rare occasions of significantly low performance, +but the long trial duration makes those occasions not so rare on the trial level. +Therefore, the binary search results tend to wander away from the noiseless end +of SUT performance spectrum, more frequently and more widely than short +trials would, thus causing poor throughput repeatability. + +The repeatability problem can be addressed by defining a search procedure +that identifies a consistent level of performance, +even if it does not meet the strict definition of throughput in [RFC2544]. + +According to the SUT performance spectrum model, better repeatability +will be at the noiseless end of the spectrum. +Therefore, solutions to the DUT in SUT problem +will help also with the repeatability problem. + +Conversely, any alteration to [RFC2544] throughput search +that improves repeatability should be considered +as less dependent on the SUT noise. + +An alternative option is to simply run a search multiple times, and report some +statistics (e.g. average and standard deviation). +This can be used +for a subset of tests deemed more important, +but it makes the search duration problem even more pronounced. + +## Throughput with Non-Zero Loss + +[RFC1242] (section 3.17 Throughput) defines throughput as: + The maximum rate at which none of the offered frames + are dropped by the device. + +Then, it says: + Since even the loss of one frame in a + data stream can cause significant delays while + waiting for the higher level protocols to time out, + it is useful to know the actual maximum data + rate that the device can support. + +However, many benchmarking teams accept a small, +non-zero loss ratio as the goal for their load search. + +Motivations are many: + +- Modern protocols tolerate frame loss better, + compared to the time when [RFC1242] and [RFC2544] were specified. + +- Trials nowadays send way more frames within the same duration, + increasing the chance of a small SUT performance fluctuation + being enough to cause frame loss. + +- Small bursts of frame loss caused by noise have otherwise smaller impact + on the average frame loss ratio observed in the trial, + as during other parts of the same trial the SUT may work more closely + to its noiseless performance, thus perhaps lowering the Trial Loss Ratio + below the Goal Loss Ratio value. + +- If an approximation of the SUT noise impact on the Trial Loss Ratio is known, + it can be set as the Goal Loss Ratio. + +Regardless of the validity of all similar motivations, +support for non-zero loss goals makes any search algorithm more user-friendly. +[RFC2544] throughput is not user-friendly in this regard. + +Furthermore, allowing users to specify multiple loss ratio values, +and enabling a single search to find all relevant bounds, +significantly enhances the usefulness of the search algorithm. + +Searching for multiple Search Goals also helps to describe the SUT performance +spectrum better than the result of a single Search Goal. +For example, the repeated wide gap between zero and non-zero loss loads +indicates the noise has a large impact on the observed performance, +which is not evident from a single goal load search procedure result. + +It is easy to modify the vanilla bisection to find a lower bound +for the intended load that satisfies a non-zero Goal Loss Ratio. +But it is not that obvious how to search for multiple goals at once, +hence the support for multiple Search Goals remains a problem. + +## Inconsistent Trial Results + +While performing throughput search by executing a sequence of +measurement trials, there is a risk of encountering inconsistencies +between trial results. + +The plain bisection never encounters inconsistent trials. +But [RFC2544] hints about the possibility of inconsistent trial results, +in two places in its text. +The first place is section 24, where full trial durations are required, +presumably because they can be inconsistent with the results +from short trial durations. +The second place is section 26.3, where two successive zero-loss trials +are recommended, presumably because after one zero-loss trial +there can be a subsequent inconsistent non-zero-loss trial. + +Examples include: + +- A trial at the same load (same or different trial duration) results + in a different Trial Loss Ratio. +- A trial at a higher load (same or different trial duration) results + in a smaller Trial Loss Ratio. + +Any robust throughput search algorithm needs to decide how to continue +the search in the presence of such inconsistencies. +Definitions of throughput in [RFC1242] and [RFC2544] are not specific enough +to imply a unique way of handling such inconsistencies. + +Ideally, there will be a definition of a new quantity which both generalizes +throughput for non-zero-loss (and other possible repeatability enhancements), +while being precise enough to force a specific way to resolve trial result +inconsistencies. +But until such a definition is agreed upon, the correct way to handle +inconsistent trial results remains an open problem. + +# MLRsearch Specification + +This section describes MLRsearch specification including all technical +definitions needed for evaluating whether a particular test procedure +complies with MLRsearch specification. + +{::comment} + [Good idea for 08, maybe ask BMWG first?] + + <mark>TODO VP: Separate Requirements and Recommendations/Suggestions + paragraphs? (currently requirements are in discussion subsections - + discussion should only clarify things without adding new + requirements)</mark> + +{:/comment} + +## Overview + +MLRsearch specification describes a set of abstract system components, +acting as functions with specified inputs and outputs. + +A test procedure is said to comply with MLRsearch specification +if it can be conceptually divided into analogous components, +each satisfying requirements for the corresponding MLRsearch component. + +The Measurer component is tasked to perform trials, +the Controller component is tasked to select trial loads and durations, +the Manager component is tasked to pre-configure everything +and to produce the test report. +The test report explicitly states Search Goals (as the Controller Inputs) +and corresponding Goal Results (Controller Outputs). + +{::comment} + [Low priority] + + <mark>MKP2 TODO: Find a good reference for the test report, seems only implicit in RFC2544.</mark> + +{:/comment} + +The Manager calls the Controller once, +the Controller keeps calling the Measurer +until all stopping conditions are met. + +The part where Controller calls the Measurer is called the search. +Any activity done by the Manager before it calls the Controller +(or after Controller returns) is not considered to be part of the search. + +MLRsearch specification prescribes regular search results and recommends +their stopping conditions. Irregular search results are also allowed, +they may have different requirements and stopping conditions. + +Search results are based on load classification. +When measured enough, any chosen load either achieves of fails each search goal, +thus becoming a lower or an upper bound for that goal. +When the relevant bounds are at loads that are close enough +(according to goal precision), the regular result is found. +Search stops when all regular results are found +(or if some goals are proven to have only irregular results). + +## Measurement Quantities + +MLRsearch specification uses a number of measurement quantities. + +In general, MLRsearch specification does not require particular units to be used, +but it is REQUIRED for the test report to state all the units. +For example, ratio quantities can be dimensionless numbers between zero and one, +but may be expressed as percentages instead. + +For convenience, a group of quantities can be treated as a composite quantity, +One constituent of a composite quantity is called an attribute, +and a group of attribute values is called an instance of that composite quantity. + +Some attributes are not independent from others, +and they can be calculated from other attributes. +Such quantites are called derived quantities. + +## Existing Terms + +RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" +contains basic definitions, and +RFC 2544 "Benchmarking Methodology for Network Interconnect Devices" +contains discussions of a number of terms and additional methodology requirements. +RFC 2285 adds more terms and discussions, describing some known situations +in more precise way. + +All three documents should be consulted +before attempting to make use of this document. + +Definitions of some central terms are copied and discussed in subsections. + +{::comment} + [Good idea for 08, but needs more work. Ask BMWG?] + + Alternatively, quick list of all (existing and new here) terms, + with links (external or internal respectively) to definitions. + + <mark>MKP3 [VP] TODO: Even if the following list will not be in final draft, + it is useful to keep it around (maybe commented-out) while editing.</mark> + + <mark>MKP3 VP note: rough list of all RFC references: + - [RFC1242] (section 3.17 Throughput) ... definition + - [RFC2544] (section 26.1 Throughput) ... methodology + - [RFC2544] (section 24. Trial duration): + - full trial durations (implies short trials) + - Also 60s for unconditional compliance is here. + - Also "the search" (without quotes) appears there. + - Also "binary search" (with quotes) appears there. + - [RFC2544] (section 26.3 Frame loss rate): + - two successive zero-loss trials are recommended (hints about loss inversion) + - un/conditionally compliant with [RFC2544] + - [RFC2544] (section 26. Benchmarking tests:) + - all its "dot sections" have "Reporting format:" paragraphs + - (implies test report) + - [RFC2544] (section 26.1 Throughput) wants graph, frame size on X axis. + - [RFC2544] (section 23. Trial description) trial + - general description of trial + - wait times specifically, maybe also learning frames? + - Constant Load of [RFC1242] (section 3.4 Constant Load) + - Data Rate of [RFC2544] (section 14. Bidirectional traffic) + - seems equal to input frame rate [RFC2544] (23. Trial description). + - [RFC2544] (section 21. Bursty traffic) suggests non-constant loads? + - Intended Load of [RFC2285] (section 3.5.1 Intended load (Iload)) + - [RFC2285] (Section 3.5.2 Offered load (Oload)) + - Frame Loss Rate of [RFC1242] (section 3.6 Frame Loss Rate) + - Forwarding Rate as defined in [RFC2285] (section 3.6.1 Forwarding rate (FR)) + - [RFC2544] (section 20. Maximum frame rate) + - [RFC2285] (3.5.3 Maximum offered load (MOL)) + - reordered frames [RFC2544] (section 10. Verifying received frames) + - For example, [RFC2544] (Appendix C) lists frame formats and protocol addresses, + as recommended from [RFC2544] (section 8. Frame formats) + and [RFC2544] (section 12. Protocol addresses). + - [RFC8219] (section 5.3. Traffic Setup) introduces traffic setups consisting of a mix of IPv4 and IPv6 traffic + - [RFC2544] (section 9. Frame sizes) + - [RFC1242] (section 3.5 Data link frame size) + - [RFC2285] (section 3.6.2) FRMOL + - [RFC2285] (section 3.1.1) DUT + - [RFC2285] (section 3.1.2) SUT + - [RFC2544] (section 6. Test set up) test setup with (an external) tester + - [RFC9004] B2B + - [RFC8219] (section 5.3. Traffic Setup) for an example of ip4+ip6 mixed traffic + </mark> + + <mark>MKP3 [VP] TODO: Do not mention those that do not need discussion here.</mark> + +{:/comment} + + +{::comment} + [Low priority] + + <mark>MKP3 [VP] TODO: Do we even need RFC9004?</mark> + +{:/comment} + +{::comment} + [I do not understand what I meant. Typos? Probably not important overall.] + + <mark>MKP2 [VP] TODO: Even terms that are discussed in this memo, + they perhaps do not need a separate list (just free paragraphs), + in a chapter after MLRsearch specification.</mark> + +{:/comment} + +{::comment} + [Important, just not enough time in 07.] + + <mark>MKP3 [VP] TODO: Verify that MLRsearch specification does not discuss + meaning of existing terms without quoting their original definition.</mark> + +{:/comment} + +### SUT + +Defined in [RFC2285] (section 3.1.2 System Under Test (SUT)) as follows. + +Definition: + +The collective set of network devices to which stimulus is offered +as a single entity and response measured. + +Discussion: + +An SUT consisting of a single network device is also allowed. + +### DUT + +Defined in [RFC2285] (section 3.1.1 Device Under Test (DUT)) as follows. + +Definition: + +The network forwarding device to which stimulus is offered and +response measured. + +Discussion: + +DUT, as a sub-component of SUT, is only indirectly mentioned +in MLRsearch specification, but is of key relevance for its motivation. + +{::comment} + [Could be useful, but not high priority.] + + ### Tester + + <mark>MKP3 TODO: Add Definition and Discusion paragraphs</mark> + + <mark>MKP3 MK note: Bizarre ... i can't find tester definition in + rfc1242, rfc2288 or rfc2544, but will keep looking. If there isn't one, + we need to define one :).</mark> + + <mark>[VP] TODO: There were some documents distinguishing TG and TA.</mark> + +{:/comment} + +### Trial + +A trial is the part of the test described in [RFC2544] (section 23. Trial description). + +Definition: + + A particular test consists of multiple trials. Each trial returns + one piece of information, for example the loss rate at a particular + input frame rate. Each trial consists of a number of phases: + + a) If the DUT is a router, send the routing update to the "input" + port and pause two seconds to be sure that the routing has settled. + + b) Send the "learning frames" to the "output" port and wait 2 + seconds to be sure that the learning has settled. Bridge learning + frames are frames with source addresses that are the same as the + destination addresses used by the test frames. Learning frames for + other protocols are used to prime the address resolution tables in + the DUT. The formats of the learning frame that should be used are + shown in the Test Frame Formats document. + + c) Run the test trial. + + d) Wait for two seconds for any residual frames to be received. + + e) Wait for at least five seconds for the DUT to restabilize. + +Discussion: + +The definition describes some traits, it is not clear whether all of them +are REQUIRED, or some of them are only RECOMMENDED. + +{::comment} + [Useful if possible.] + + <mark>MKP2 [VP] TODO: Search RFCs for better description of "Run the test trial".</mark> + +{:/comment} + +For the purposes of the MLRsearch specification, +it is ALLOWED for the test procedure to deviate from the [RFC2544] description, +but any such deviation MUST be made explicit in the test report. + +Trials are the only stimuli the SUT is expected to experience +during the search. + +In some discussion paragraphs, it is useful to consider the traffic +as sent and received by a tester, as implicitly defined +in [RFC2544] (section 6. Test set up). + +An example of deviation from [RFC2544] is using shorter wait times. + +## Trial Terms + +This section defines new and redefine existing terms for quantities +relevant as inputs or outputs of trial, as used by the Measurer component. + +### Trial Duration + +Definition: + +Trial duration is the intended duration of the traffic for a trial. + +Discussion: + +In general, this quantity does not include any preparation nor waiting +described in section 23 of [RFC2544] (section 23. Trial description). + +While any positive real value may be provided, some Measurer implementations +MAY limit possible values, e.g. by rounding down to neared integer in seconds. +In that case, it is RECOMMENDED to give such inputs to the Controller +so the Controller only proposes the accepted values. +Alternatively, the test report MUST present the rounded values +as Search Goal attributes. + +### Trial Load + +Definition: + +The trial load is the intended load for a trial + +Discussion: + +For test report purposes, it is assumed that this is a constant load by default. +This MAY be only an average load, e.g. when the traffic is intended to be busty, +e.g. as suggested in [RFC2544] (section 21. Bursty traffic), +but the test report MUST explicitly mention how non-constant the traffic is. + +Trial load is the quantity defined as Constant Load of [RFC1242] +(section 3.4 Constant Load), Data Rate of [RFC2544] +(section 14. Bidirectional traffic) +and Intended Load of [RFC2285] (section 3.5.1 Intended load (Iload)). +All three definitions specify +that this value applies to one (input or output) interface. + +{::comment} + [Not important.] + + <mark>MKP2 [VP] TODO: Also mention input frame rate [RFC2544] (23. Trial description).</mark> + +{:/comment} + +For test report purposes, multi-interface aggregate load MAY be reported, +this is understood as the same quantity expressed using different units. +From the report it MUST be clear whether a particular trial load value +is per one interface, or an aggregate over all interfaces. + +Similarly to trial duration, some Measurers may limit the possible values +of trial load. Contrary to trial duration, the test report is NOT REQUIRED +to document such behavior. + +{::comment} + [Can of worms. Be aware, but probably do not let spill into draft.] + + <mark>MKP2 [VP] TODO: Why? In practice the difference is small, but what if it is big? + Do we need Trial Effective Load for bounds an conditional throughput purposes? + Should the Controller be recommended to chose load values that are exactly accepted? + </mark> + +{:/comment} + +It is ALLOWED to combine trial load and trial duration in a way +that would not be possible to achieve using any integer number of data frames. + +{::comment} + [I feel this is important, to be discussed separately (not in-scope).] + + <mark>MKP2 [VP] TODO: Explain why are we not using Oload. + 1. MLRsearch implementations cannot react correctly to big differences + between Iload and Oload. + 2. The media between the tested and the DUT are thus considered to be part of SUT. + If DUT causes congestion control, it is not expected to handle Iload. + </mark> + + See further discussion in [Trial Forwarding Ratio] (#Trial-Forwarding-Ratio) + and in [Measurer] (#Measurer) sections for other related issues. + + <mark>MKP2 [VP] TODO: Create a separate subsection for Oload discussion, + or clearly separate which aspects are discussed under which term.</mark> + + <mark>MKP2 [VP] TODO: New idea. Compare the tester to an ordinary router + in some datacenter. The Intended Load is not jst some abstract input. + It is the real traffic coming from routers next hop farther. + It does not matter that DUT has forwarded each frame it received, + if the tester was unable to sent all the traffic in time. + Endpoint see packet loss, they do not care about [RFC2285] + half-duplex, spanning trees, nor congestion control mechanisms. + Formally speaking, I consider even the sending interface of the sender + to be the part of SUT. + Reading [RFC2285] (section 3.5.3 Maximum offered load (MOL)) + "This will be the case when an external source lacks the resources + to transmit frames at the minimum legal inter-frame gap" + that means TRex workers are also part of SUT. If they do not have + enough CPU power to generate frames are required, those frames are lost. + </mark> + + <mark>MKP2 [VP] TODO: That new idea warants some discussion in "DUT within SUT", + as it is just another case of ther rest of SUT ruining + otherwise good DUT performance.</mark> + +{:/comment} + +### Trial Input + +Definition: + +Trial Input is a composite quantity, consisting of two attributes: +trial duration and trial load. + +Discussion: + +When talking about multiple trials, it is common to say "Trial Inputs" +to denote all corresponding Trial Input instances. + +A Trial Input instance acts as the input for one call of the Measurer component. + +Contrary to other composite quantities, MLRsearch implementations +are NOT ALLOWED to add optional attributes here. +This improves interoperability between various implementations of +the Controller and the Measurer. + +### Traffic Profile + +Definition: + +Traffic profile is a composite quantity +containing attributes other than trial load and trial duration, +needed for unique determination of the trial to be performed. + +Discussion: + +All its attributes are assumed to be constant during the search, +and the composite is configured on the Measurer by the Manager +before the search starts. +This is why the traffic profile is not part of the Trial Input. + +As a consequence, implementations of the Manager and the Measurer +must be aware of their common set of capabilities, so that the traffic profile +uniquely defines the traffic during the search. +The important fact is that none of those capabilities +have to be known by the Controller implementations. + +The traffic profile SHOULD contain some specific quantities, +for example [RFC2544] (section 9. Frame sizes) governs +data link frame size as defined in [RFC1242] (section 3.5 Data link frame size). + +Several more specific quantities may be RECOMMENDED, depending on media type. +For example, [RFC2544] (Appendix C) lists frame formats and protocol addresses, +as recommended from [RFC2544] (section 8. Frame formats) +and [RFC2544] (section 12. Protocol addresses). + +Depending on SUT configuration, e.g. when testing specific protocols, +additional attributes MUST be included in the traffic profile +and in the test report. + +Example: [RFC8219] (section 5.3. Traffic Setup) introduces traffic setups +consisting of a mix of IPv4 and IPv6 traffic - the implied traffic profile +therefore must include an attribute for their percentage. + +Other traffic properties that need to be somehow specified +in Traffic Profile include: +[RFC2544] (section 14. Bidirectional traffic), +[RFC2285] (section 3.3.3 Fully meshed traffic), +and [RFC2544] (section 11. Modifiers). + +### Trial Forwarding Ratio + +Definition: + +The trial forwarding ratio is a dimensionless floating point value. +It MUST range between 0.0 and 1.0, both inclusive. +It is calculated by dividing the number of frames +successfully forwarded by the SUT +by the total number of frames expected to be forwarded during the trial + +Discussion: + +For most traffic profiles, "expected to be forwarded" means +"intended to get transmitted from Tester towards SUT". + +Trial forwarding ratio MAY be expressed in other units +(e.g. as a percentage) in the test report. + +Note that, contrary to loads, frame counts used to compute +trial forwarding ratio are aggregates over all SUT output interfaces. + +Questions around what is the correct number of frames +that should have been forwarded +is generally outside of the scope of this document. + +{::comment} + [Part two of iload/oload discussion.] + + See discussion in [Measurer] (#Measurer) section + for more details about calibrating test equipment. + + <mark>MKP2 [VP] TODO: Define unsent frames?</mark> + + <mark>MKP2 [VP] TODO: If Oload is fairly below Iload, the unsent frames + should be counted as lost, otherwise search outputs are misleading. + But what is "fairly"? CSIT tolerates 10 microseconds worth of unsent frames.</mark> + +{:/comment} + +{::comment} + [Low priority, but maybe useful for somebody?] + + <mark>MKP2 [VP] TODO: Mention traffic profiles with uneven frame counts? + E.g. when SUT is expected to perform IP packet fragmentation or reassembly. + </mark> + +{:/comment} + +### Trial Loss Ratio + +Definition: + +The Trial Loss Ratio is equal to one minus the trial forwarding ratio. + +Discussion: + +100% minus the trial forwarding ratio, when expressed as a percentage. + +This is almost identical to Frame Loss Rate of [RFC1242] +(section 3.6 Frame Loss Rate), +the only minor difference is that Trial Loss Ratio +does not need to be expressed as a percentage. + +### Trial Forwarding Rate + +Definition: + +The trial forwarding rate is a derived quantity, calculated by +multiplying the trial load by the trial forwarding ratio. + +Discussion: + +It is important to note that while similar, this quantity is not identical +to the Forwarding Rate as defined in [RFC2285] +(section 3.6.1 Forwarding rate (FR)). +The latter is specific to one output interface only, +whereas the trial forwarding ratio is based +on frame counts aggregated over all SUT output interfaces. + +{::comment} + [Part 3 of iload/oload discussion.] + + <mark>MKP2 [VP] TODO: If some unsent frames were tolerated (not counted as lost), + this value is actually higher than the real fps output of the SUT. + Should we use the real FR as the basis for Conditional Throughput + (instead of this TFR)? That would require additional Trial Output attribute. + </mark> + + <mark>MKP2 [VP] TODO: What about duration stretching? + This also causes difference between Iload and Oload, + but in an invisible way.</mark> + + <mark>MKP2 [VP] TODO: Recommend start+sleep+stop? + How long wait for late frames? RFC2544 2s is too much even at 30s trial.</mark> + +{:/comment} + +### Trial Effective Duration + +Definition: + +Trial effective duration is a time quantity related to the trial, +by default equal to the trial duration. + +Discussion: + +This is an optional feature. +If the Measurer does not return any trial effective duration value, +the Controller MUST use the trial duration value instead. + +Trial effective duration may be any time quantity chosen by the Measurer +to be used for time-based decisions in the Controller. + +The test report MUST explain how the Measurer computes the returned +trial effective duration values, if they are not always +equal to the trial duration. + +This feature can be beneficial for users +who wish to manage the overall search duration, +rather than solely the traffic portion of it. +Simply measure the duration of the whole trial (waits including) +and use that as the trial effective duration. + +Also, this is a way for the Measurer to inform the Controller about +its surprising behavior, for example when rounding the trial duration value. + +{::comment} + [Not very important, but easy and nice recommendation.] + + <mark>MKP2 [VP] TODO: Recommend for Measurer to return all trials at relevant bounds, + as that may better inform users when surprisingly small amount of trials + was performed, just because the the trial effective duration values were big.</mark> + + <mark>MKP2 [VP] TODO: Repeat that this is not here to deal with duration stretching.</mark> + +{:/comment} + +### Trial Output + +Definition: + +Trial Output is a composite quantity. The REQUIRED attributes are +Trial Loss Ratio, trial effective duration and trial forwarding rate. + +Discussion: + +When talking about multiple trials, it is common to say "Trial Outputs" +to denote all corresponding Trial Output instances. + +Implementations may provide additional (optional) attributes. +The Controller implementations MUST ignore values of any optional attribute +they are not familiar with, +except when passing Trial Output instance to the Manager. + +Example of an optional attribute: +The aggregate number of frames expected to be forwarded during the trial, +especially if it is not just (a rounded-up value) +implied by trial load and trial duration. + +While [RFC2285] (Section 3.5.2 Offered load (Oload)) +requires the offered load value to be reported for forwarding rate measurements, +it is NOT REQUIRED in MLRsearch specification. + +{::comment} + [Side tangent from iload/oload discussion. Stilll recommendation is not obvious.] + + <mark>MKP2 TODO: Why? Just because bound trial results are optional in Controller Output?</mark> + + <mark>MKP2 mk edit note: we need to more explicitly address + the relevance or irrelevance of [RFC2285] (Section 3.5.2 Offered load (Oload)). + Current text in [Trial Load] (#Trial-Load) is ambiguous - quoted below.</mark> + + <mark>MKP2 "Questions around what is the correct number of frames that should + have been forwarded is generally outside of the scope of this document. + See discussion in [Measurer] (#Measurer) section for more details about + calibrating test equipment."</mark> + +{:/comment} + +### Trial Result + +Definition: + +Trial result is a composite quantity, +consisting of the Trial Input and the Trial Output. + +Discussion: + +When talking about multiple trials, it is common to say "trial results" +to denote all corresponding trial result instances. + +While implementations SHOULD NOT include additional attributes +with independent values, they MAY include derived quantities. + +## Goal Terms + +This section defines new and redefine existing terms for quantities +indirectly relevant for inputs or outputs of the Controller component. + +Several goal attributes are defined before introducing +the main component quantity: the Search Goal. + +### Goal Final Trial Duration + +Definition: + +A threshold value for trial durations. + +Discussion: + +This attribute value MUST be positive. + +A trial with Trial Duration at least as long as the Goal Final Trial Duration +is called a full-length trial (with respect to the given Search Goal). + +A trial that is not full-length is called a short trial. + +Informally, while MLRsearch is allowed to perform short trials, +the results from such short trials have only limited impact on search results. + +One trial may be full-length for some Search Goals, but not for others. + +The full relation of this goal to Controller Output is defined later in +this document in subsections of [Goal Result] (#Goal-Result). +For example, the Conditional Throughput for this goal is computed only from +full-length trial results. + +### Goal Duration Sum + +Definition: + +A threshold value for a particular sum of trial effective durations. + +Discussion: + +This attribute value MUST be positive. + +Informally, even when looking only at full-length trials, +MLRsearch may spend up to this time measuring the same load value. + +If the Goal Duration Sum is larger than the Goal Final Trial Duration, +multiple full-length trials may need to be performed at the same load. + +See [TST009 Example] (#TST009-Example) for an example where possibility +of multiple full-length trials at the same load is intended. + +A Goal Duration Sum value lower than the Goal Final Trial Duration +(of the same goal) could save some search time, but is NOT RECOMMENDED. +See [Relevant Upper Bound] (#Relevant-Upper-Bound) for partial explanation. + +### Goal Loss Ratio + +Definition: + +A threshold value for Trial Loss Ratios. + +Discussion: + +Attribute value MUST be non-negative and smaller than one. + +A trial with Trial Loss Ratio larger than a Goal Loss Ratio value +is called a lossy trial, with respect to given Search Goal. + +Informally, if a load causes too many lossy trials, +the Relevant Lower Bound for this goal will be smaller than that load. + +If a trial is not lossy, it is called a low-loss trial, +or (specifically for zero Goal Loss Ratio value) zero-loss trial. + +### Goal Exceed Ratio + +Definition: + +A threshold value for a particular ratio of sums of Trial Effective Durations. + +Discussion: + +Attribute value MUST be non-negative and smaller than one. + +See later sections for details on which sums. +Specifically, the direct usage is only in +[Appendix A: Load Classification] (#Appendix-A\:-Load-Classification) +and [Appendix B: Conditional Throughput] (#Appendix-B\:-Conditional-Throughput). +The impact of that usage is discussed in subsections leading to +[Goal Result] (#Goal-Result). + +Informally, the impact of lossy trials is controlled by this value. +Effectively, Goal Exceed Ratio is a percentage of full-length trials +that may be lossy without the load being classified +as the [Relevant Upper Bound] (#Relevant-Upper-Bound). + +### Goal Width + +Definition: + +A value used as a threshold for deciding +whether two trial load values are close enough. + +Discussion: + +If present, the value MUST be positive. + +Informally, this acts as a stopping condition, +controlling the precision of the search. +The search stops if every goal has reached its precision. + +Implementations without this attribute +MUST give the Controller other ways to control the search stopping conditions. + +Absolute load difference and relative load difference are two popular choices, +but implementations may choose a different way to specify width. + +The test report MUST make it clear what specific quantity is used as Goal Width. + +It is RECOMMENDED to set the Goal Width (as relative difference) value +to a value no smaller than the Goal Loss Ratio. +(The reason is not obvious, see [Throughput] (#Throughput) if interested.) + +### Search Goal + +Definition: + +The Search Goal is a composite quantity consisting of several attributes, +some of them are required. + +Required attributes: +- Goal Final Trial Duration +- Goal Duration Sum +- Goal Loss Ratio +- Goal Exceed Ratio + +Optional attribute: +- Goal Width + +Discussion: + +Implementations MAY add their own attributes. +Those additional attributes may be required by the implementation +even if they are not required by MLRsearch specification. +But it is RECOMMENDED for those implementations +to support missing values by computing reasonable defaults. + +The meaning of listed attributes is formally given only by their indirect effect +on the search results. + +Informally, later sections provide additional intuitions and examples +of the Search Goal attribute values. + +An example of additional attributes required by some implementations +is Goal Initial Trial Duration, together with another attribute +that controls possible intermediate Trial Duration values. +The reasonable default in this case is using the Goal Final Trial Duration +and no intermediate values. + +### Controller Input + +Definition: + +Controller Input is a composite quantity +required as an input for the Controller. +The only REQUIRED attribute is a list of Search Goal instances. + +Discussion: + +MLRsearch implementations MAY use additional attributes. +Those additional attributes may be required by the implementation +even if they are not required by MLRsearch specification. + +Formally, the Manager does not apply any Controller configuration +apart from one Controller Input instance. + +For example, Traffic Profile is configured on the Measurer by the Manager +(without explicit assistance of the Controller). + +The order of Search Goal instances in a list SHOULD NOT +have a big impact on Controller Output (see section [Controller Output] (#Controller-Output) , +but MLRsearch implementations MAY base their behavior on the order +of Search Goal instances in a list. + +An example of an optional attribute (outside the list of Search Goals) +required by some implementations is Max Load. +While this is a frequently used configuration parameter, +already governed by [RFC2544] (section 20. Maximum frame rate) +and [RFC2285] (3.5.3 Maximum offered load (MOL)), +some implementations may detect or discover it instead. + +{::comment} + [Not important directly, may matter for iload/oload.] + + <mark>MKP2 [VP] TODO: 2544 and 2285 care about half-duplex media. Should we?</mark> + +{:/comment} + +{::comment} + [Maybe obvious but I think useful. RFC2544 talks about header compression in WANs.] + + <mark>MKP2 [VP] TODO: Mention that Max Load should care about all media within SUT, + including DUT-DUT links. Important when that link carries encapsulated traffic, + as bandwidth limit there implies lower max rate + (than implied by tester-SUT links).</mark> + +{:/comment} + +In MLRsearch specification, the [Relevant Upper Bound] (#Relevant-Upper-Bound) +is added as a required attribute precisely because it makes the search result +independent of Max Load value. + +{::comment} + [User recommendation, we should have separate section summarizing those.] + + <mark>[VP] TODO for MK: The rest of this subsection is new, review?</mark> + + It is RECOMMENDED to use the same Goal Final Trial Duration value across all goals. + Otherwise, some goals may be measured at Trial Durations longer than needed, + with possibly unexpected impacts on repeatability and comparability. + + For example when Goal Loss Ratio is zero, any increase in Trial Duration + also increases the likelihood of the trial to become lossy, + similar to usage of lower Goal Exceed Ratio or larger Goal Duration Sum, + both of which tend to lower the search results, towards noisy end + of performance spectrum. + + Also, it is recommended to avoid "incomparable" goals, e.g. one with + lower loss ratio but higher exceed ratio, and other with higher loss ratio + but lower loss ratio. In worst case, this can make the search to last too long. + Implementations are RECOMMENDED to sort the goals and start with + stricter ones first, as bounds for those will not get invalidated + byt measureing for less trict goal later in the search. + +{:/comment} + +## Search Goal Examples + +### RFC2544 Goal + +The following set of values makes the search result unconditionally compliant +with [RFC2544] (section 24 Trial duration) + +- Goal Final Trial Duration = 60 seconds +- Goal Duration Sum = 60 seconds +- Goal Loss Ratio = 0% +- Goal Exceed Ratio = 0% + +The latter two attributes are enough to make the search goal +conditionally compliant, adding the first attribute +makes it unconditionally compliant. + +The second attribute (Goal Duration Sum) only prevents MLRsearch +from repeating zero-loss full-length trials. + +Non-zero exceed ratio could prolong the search and allow loss inversion +between lower-load lossy short trial and higher-load full-length zero-loss trial. +From [RFC2544] alone, it is not clear whether that higher load +could be considered as compliant throughput. + +### TST009 Goal + +One of the alternatives to RFC2544 is described in +[TST009] (section 12.3.3 Binary search with loss verification). +The idea there is to repeat lossy trials, hoping for zero loss on second try, +so the results are closer to the noiseless end of performance sprectum, +and more repeatable and comparable. + +Only the variant with "z = infinity" is achievable with MLRsearch. + +{::comment} + [Low priority, unless a short sentence is found.] + + <mark>MKP2 MK note: Shouldn't we add a note about how MLRsearch goes about + addressing the TST009 point related to z, that is "z is threshold of + Lord(r) to override Loss Verification when the count of lost frames is + very high and unnecessary verification trials."? i.e. by have Goal Loss + Ratio. Thoughts?</mark> + +{:/comment} + +For example, for "r = 2" variant, the following search goal should be used: + +- Goal Final Trial Duration = 60 seconds +- Goal Duration Sum = 120 seconds +- Goal Loss Ratio = 0% +- Goal Exceed Ratio = 50% + +If the first 60s trial has zero loss, it is enough for MLRsearch to stop +measuring at that load, as even a second lossy trial +would still fit within the exceed ratio. + +But if the first trial is lossy, MLRsearch needs to perform also +the second trial to classify that load. +As Goal Duration Sum is twice as long as Goal Final Trial Duration, +third full-length trial is never needed. + +## Result Terms + +Before defining the output of the Controller, +it is useful to define what the Goal Result is. + +The Goal Result is a composite quantity. + +Following subsections define its attribute first, before describing the Goal Result quantity. + +There is a correspondence between Search Goals and Goal Results. +Most of the following subsections refer to a given Search Goal, +when defining attributes of the Goal Result. +Conversely, at the end of the search, each Search Goal +has its corresponding Goal Result. + +Conceptually, the search can be seen as a process of load classification, +where the Controller attempts to classify some loads as an Upper Bound +or a Lower Bound with respect to some Search Goal. + +Before defining real attributes of the goal result, +it is useful to define bounds in general. + +### Relevant Upper Bound + +Definition: + +The Relevant Upper Bound is the smallest trial load value that is classified +at the end of the search as an upper bound +(see [Appendix A: Load Classification] (#Appendix-A\:-Load-Classification)) +for the given Search Goal. + +Discussion: + +One search goal can have many different load classified as an upper bound. +At the end of the search, one of those loads will be the smallest, +becoming the relevant upper bound for that goal. + +In more detail, the set of all trial outputs (both short and full-length, +enough of them according to Goal Duration Sum) +performed at that smallest load failed to uphold all the requirements +of the given Search Goal, mainly the Goal Loss Ratio +in combination with the Goal Exceed Ratio. + +{::comment} + [Recheck. Move to end?] + + <mark>[VP] TODO: Is the above a good summary of Appendix A inputs?</mark> + +{:/comment} + +If Max Load does not cause enough lossy trials, +the Relevant Upper Bound does not exist. +Conversely, if Relevant Upper Bound exists, +it is not affected by Max Load value. + +{::comment} + [Medium priority, depends on how many user recommendations we have.] + + With non-zero exceed ratio values, a lossy short trial may not be enough + to classify a load as the relevant upper bound. + Users MAY apply Goal Duration Sum value lower than Goal Final Trial Duration + to force such classification in hope to save time, + but it is RECOMMENDED not to do so, as in practice + it hurts comparability and repeatability. + +{:/comment} + +{::comment} + [Probably too technical, unless relation to repeatability is found.] + + In general, a load starts as as undecided, then maybe flips to become + an upper bound. MLRsearch stops measuring at that load for this goal, + but it may be forced to measure more for some other search goals, + in which case the load may flip to a lower bound (and back and forth). + + <mark>[VP] TODO: Confirm the load can never flip back to being undecided.</mark> + + Even though the load classification may change during the search, + the goal results are established at the end of the search. + + If the exceed ratio is zero, an upper bound can never flip; + one lossy trial (even short) is enough to pin the classification. + +{:/comment} + +### Relevant Lower Bound + +Definition: + +The Relevant Lower Bound is the largest trial load value +among those smaller than the Relevant Upper Bound, +that got classified at the end of the search as a lower bound (see +[Appendix A: Load Classification] (#Appendix-A\:-Load-Classification)) +for the given Search Goal. + +Discussion: + +Only among loads smaller that the relevant upper bound, +the largest load becomes the relevant lower bound. +With loss inversion, stricter upper bound matters. + +In more detail, the set of all trial outputs (both short and full-length, +enough of them according to Goal Duration Sum) +performed at that largest load managed to uphold all the requirements +of the given Search Goal, mainly the Goal Loss Ratio +in combination with the Goal Exceed Ratio. + +Is no load had enough low-loss trials, the relevant lower bound +MAY not exist. + +{::comment} + [Min Load us useful for detecting broken SUTs (and latency).] + + <mark>[VP] TODO: Mention min load here?</mark> + + <mark>[VP] TODO: Allow zero as implicit lower bound that needs no trials? + If yes, then probably way earlier than here.</mark> + +{:/comment} + +Strictly speaking, if the Relevant Upper Bound does not exist, +the Relevant Lower Bound also does not exist. +In that case, Max Load is classified as a lower bound, +but it is not clear whether a higher lower bound +would be found if the search used a higher Max Load value. + +For a regular Goal Result, the distance between the Relevant Lower Bound +and the Relevant Upper Bound MUST NOT be larger than the Goal Width, +if the implementation offers width as a goal attribute. + +{::comment} + [True but no time to fix properly.] + + <mark>mk note: Seemingly broken grammar, + "managed to uphold all requirements", should be followed + by stating what it means.</mark> + +{:/comment} + +Searching for anther search goal may cause a loss inversion phenomenon, +where a lower load is classified as an upper bound, +but also a higher load is classified as a lower bound for the same search goal. +The definition of the Relevant Lower Bound ignores such high lower bounds. + +{::comment} + [Compare to similar block in upper bound.] + + In general, a load starts as as undecided, then maybe flips to become + a lower bound. MLRsearch stops measuring at that load for this goal, + but it may be forced to measure more for some other search goals, + in which case the load may flip to an upper bound (and back and forth). + + <mark>[VP] TODO: Confirm the load can never flip back to being undecided.</mark> + + Even though the load classification may change during the search, + the goal results are established at the end of the search. + + No valid exceed ratio value pins the classification as a lower bound. + +{:/comment} + +### Conditional Throughput + +Definition: + +The Conditional Throughput (see section [Appendix B: Conditional Throughput] (#Appendix-B\:-Conditional-Throughput)) +as evaluated at the Relevant Lower Bound of the given Search Goal +at the end of the search. + +Discussion: + +Informally, this is a typical trial forwarding rate, expected to be seen +at the Relevant Lower Bound of the given Search Goal. + +But frequently it is only a conservative estimate thereof, +as MLRsearch implementations tend to stop gathering more data +as soon as they confirm the value cannot get worse than this estimate +within the Goal Duration Sum. + +This value is RECOMMENDED to be used when evaluating repeatability +and comparability if different MLRsearch implementations. + +{::comment} + [Low priority but useful for comparabuility.] + + <mark>[VP] TODO: Add subsection for Trial Results At Relevant Bounds + as an optional attribute of Goal Result.</mark> + +{:/comment} + +### Goal Result + +Definition: + +The Goal Result is a composite quantity consisting of several attributes. +Relevant Upper Bound and Relevant Lower Bound are REQUIRED attributes, +Conditional Throughput is a RECOMMENDED attribute. + +Discussion: + +Depending on SUT behavior, it is possible that one or both relevant bounds +do not exist. The goal result instance where the required attribute values exist +is informally called a Regular Goal Result instance, +so we can say some goals reached Irregular Goal Results. + +{::comment} + [Probably delete after last edits re irregular results.] + + <mark>MKP2 [VP] TODO: Additional attributes should not be required by the Manager? + Explicitly mention that irregular goal result may support different attributes. + </mark> + + <mark>MKP2 Implementations are free to define their own specific subtypes + of irregular Goal Results, but the test report MUST mark them clearly + as irregular according to this section.</mark> + +{:/comment} + +A typical Irregular Goal Result is when all trials at the Max Load +have zero loss, as the Relevant Upper Bound does not exist in that case. + +It is RECOMMENDED that the test report will display such results appropriately, +although MLRsearch specification does not prescibe how. + +{::comment} + [Useful.] + + <mark>MKP2 [VP] TODO: Also allways-fail. Link to bounds to avoid duplication.</mark> + +{:/comment} + +Anything else regarging Irregular Goal Results, +including their role in stopping conditions of the search +is outside the scope of this document. + +### Search Result + +Definition: + +The Search Result is a single composite object +that maps each Search Goal instance to a corresponding Goal Result instance. + +Discussion: + +Alternatively, the Search Result can be implemented as an ordered list +of the Goal Result instances, matching the order of Search Goal instances. + +{::comment} + [Low priority, as there is no obvious harm.] + + <mark>MKP1 [VP] TODO: Disallow any additional attributes?</mark> + +{:/comment} + +The Search Result (as a mapping) +MUST map from all the Search Goal instances present in the Controller Input. + +{::comment} + [Not important.] + + <mark>[VP] Postponed: API independence, modularity.</mark> + +{:/comment} + +{::comment} + [Not needed?] + + <mark>MKP1 [VP] TODO: Short sentence on what to do on irregular goal result.</mark> + +{:/comment} + +### Controller Output + +Definition: + +The Controller Output is a composite quantity returned from the Controller +to the Manager at the end of the search. +The Search Result instance is its only REQUIRED attribute. + +Discussion: + +MLRsearch implementation MAY return additional data in the Controller Output. + +{::comment} + [Not needed?] + + <mark>MKP1 [VP] TODO: Short sentence on what to do on irregular goal result.</mark> + + <mark>MKP1 [VP] TODO: Irregular output, e.g. with "max search time exceeded" flag?</mark> + +{:/comment} + +## MLRsearch Architecture + +{::comment} + [Meta and irrelevant. Delete after verifying other text is good.] + + <mark>MKP2 [VP] TODO: Review the folowing: + This section is about division into components, + so it fits this definition: + "The software architecture of a system represents the design decisions + related to overall system structure and behavior." + Saying "MLRsearch Design" does not make it clear if it is + Vratko designing the MLRsearch specification, + or some other person designing a new MLRsearch implementation using that spec. + </mark> + +{:/comment} + +MLRsearch architecture consists of three main system components: +the Manager, the Controller, and the Measurer. + +The architecture also implies the presence of other components, +such as the SUT and the Tester (as a sub-component of the Measurer). + +Protocols of communication between components are generally left unspecified. +For example, when MLRsearch specification mentions "Controller calls Measurer", +it is possible that the Controller notifies the Manager +to call the Measurer indirectly instead. This way the Measurer implementations +can be fully independent from the Controller implementations, +e.g. programmed in different programming languages. + +### Measurer + +Definition: + +The Measurer is an abstract system component +that when called with a [Trial Input] (#Trial-Input) instance, +performs one [Trial] (#Trial), +and returns a [Trial Output] (#Trial-Output) instance. + +Discussion: + +This definition assumes the Measurer is already initialized. +In practice, there may be additional steps before the search, +e.g. when the Manager configures the traffic profile +(either on the Measurer or on its tester sub-component directly) +and performs a warmup (if the tester requires one). + +It is the responsibility of the Measurer implementation to uphold +any requirements and assumptions present in MLRsearch specification, +e.g. trial forwarding ratio not being larger than one. + +Implementers have some freedom. +For example [RFC2544] (section 10. Verifying received frames) +gives some suggestions (but not requirements) related to +duplicated or reordered frames. +Implementations are RECOMMENDED to document their behavior +related to such freedoms in as detailed a way as possible. + +It is RECOMMENDED to benchmark the test equipment first, +e.g. connect sender and receiver directly (without any SUT in the path), +find a load value that guarantees the offered load is not too far +from the intended load, and use that value as the Max Load value. +When testing the real SUT, it is RECOMMENDED to turn any big difference +between the intended load and the offered load into increased Trial Loss Ratio. + +Neither of the two recommendations are made into requirements, +because it is not easy to tell when the difference is big enough, +in a way thay would be dis-entangled from other Measurer freedoms. + +### Controller + +Definition: + +The Controller is an abstract system component +that when called with a Controller Input instance +repeatedly computes Trial Input instance for the Measurer, +obtains corresponding Trial Output instances, +and eventually returns a Controller Output instance. + +Discussion: + +Informally, the Controller has big freedom in selection of Trial Inputs, +and the implementations want to achieve the Search Goals +in the shortest expected time. + +The Controller's role in optimizing the overall search time +distinguishes MLRsearch algorithms from simpler search procedures. + +Informally, each implementation can have different stopping conditions. +Goal Width is only one example. +In practice, implementation details do not matter, +as long as Goal Results are regular. + +### Manager + +Definition: + +The Manager is an abstract system component that is reponsible for +configuring other components, calling the Controller component once, +and for creating the test report following the reporting format as +defined in [RFC2544] (section 26. Benchmarking tests). + +Discussion: + +The Manager initializes the SUT, the Measurer (and the Tester if independent) +with their intended configurations before calling the Controller. + +The Manager does not need to be able to tweak any Search Goal attributes, +but it MUST report all applied attribute values even if not tweaked. + +{::comment} + [Not very important but also should be easy to add.] + + <mark>MKP2 [VP] TODO: Is saying "RFC2544" indirectly reporting RFC2544 Goal values?</mark> + +{:/comment} + +In principle, there should be a "user" (human or CI) +that "starts" or "calls" the Manager and receives the report. +The Manager MAY be able to be called more than once whis way. + +{::comment} + [Not important, unless anybody else asks.] + + <mark>MKP2 The Manager may use the Measurer or other system components + to perform other tests, e.g. back-to-back frames, + as the Controller is only replacing the search from + [RFC2544] (section 26.1 Throughput).</mark> + +{:/comment} + +## Implementation Compliance + +Any networking measurement setup where there can be logically delineated system components +and there are components satisfying requirements for the Measurer, +the Controller and the Manager, is considered to be compliant with MLRsearch design. + +These components can be seen as abstractions present in any testing procedure. +For example, there can be a single component acting both +as the Manager and the Controller, but as long as values of required attributes +of Search Goals and Goal Results are visible in the test report, +the Controller Input instance and output instance are implied. + +For example, any setup for conditionally (or unconditionally) +compliant [RFC2544] throughput testing +can be understood as a MLRsearch architecture, +assuming there is enough data to reconstruct the Relevant Upper Bound. + +See [RFC2544 Goal] (#RFC2544-Goal) subsection for equivalent Search Goal. + +Any test procedure that can be understood as (one call to the Manager of) +MLRsearch architecture is said to be compliant with MLRsearch specification. + +# Additional Considerations + +This section focuses on additional considerations, intuitions and motivations +pertaining to MLRsearch methodology. + +{::comment} + [Meta, redundant.] + + <mark>MKP2 [VP] TODO: Review the following: + If MLRsearch specification is a product design specification + for MLRsearch implementation, then this chapter talks about + my goals and early attempts at designing the MLRsearch specification. + </mark> + +{:/comment} + +## MLRsearch Versions + +The MLRsearch algorithm has been developed in a code-first approach, +a Python library has been created, debugged, used in production +and published in PyPI before the first descriptions +(even informal) were published. + +But the code (and hence the description) was evolving over time. +Multiple versions of the library were used over past several years, +and later code was usually not compatible with earlier descriptions. + +The code in (some version of) MLRsearch library fully determines +the search process (for a given set of configuration parameters), +leaving no space for deviations. + +{::comment} + [Different type of external link, should be in 08.] + + <mark>MKP2 mk3 note: any references to library + should have specific reference link. + We have FDio-CSIT-MLRsearch in informative: at the start. Link it. + </mark> + +{:/comment} + +{::comment} + [Lesson learned is important, but maybe does not need version history?] + + <mark>MKP2 mk edit note: Suggest to remove crossed-out text, as it is + distracting, doesn't bring any value, and recalls multiple versions of + MLRsearch library, without any references. A much more appropriate + approach would be to provide a pointer to MLRsearch code versions in + FD.io that evolved over the years, as an example implementation. But I + would question the value of referring to old previous versions in this + document. It's okay for the blog, but not for IETF specification, + unless there are specific lessons learned that need to be highlighted + to support the specification.</mark> + +{:/comment} + +This historic meaning of MLRsearch, as a family +of search algorithm implementations, +leaves plenty of space for future improvements, at the cost +of poor comparability of results of search algoritm implementations. + +{::comment} + [Reckeck after clarifying library/algorithm/implementation/specification mess.] + + <mark>mk edit note: If the aim of this sentence is to state that there + could be possibly other approaches to address this problem space, then + I think we are already addressing it in the opening sections discussing + problems, and referring to ETSi TST.009 and opnfv work. If the aim is + to define "MLRsearch" as a completely new class of algorithms for + software network benchmarking, of which this spec is just one example, + then i have a problem with it. This specification is very prescriptive + in the main functional areas to address the problem identified, but + still leaving space for further exploration and innovation as noted + elsewhere in this document. It is not a new class of algorithms. It is + a newly defined methodology to amend RFC2544, to specifically address + identified problems.</mark> + +{:/comment} + +There are two competing needs. +There is the need for standardization in areas critical to comparability. +There is also the need to allow flexibility for implementations +to innovate and improve in other areas. +This document defines MLRsearch as a new specification +in a manner that aims to fairly balance both needs. + +## Stopping Conditions + +[RFC2544] prescribes that after performing one trial at a specific offered load, +the next offered load should be larger or smaller, based on frame loss. + +The usual implementation uses binary search. +Here a lossy trial becomes +a new upper bound, a lossless trial becomes a new lower bound. +The span of values between the tightest lower bound +and the tightest upper bound (including both values) forms an interval of possible results, +and after each trial the width of that interval halves. + +Usually the binary search implementation tracks only the two tightest bounds, +simply calling them bounds. +But the old values still remain valid bounds, +just not as tight as the new ones. + +After some number of trials, the tightest lower bound becomes the throughput. +[RFC2544] does not specify when, if ever, should the search stop. + +MLRsearch introduces a concept of [Goal Width] (#Goal-Width). + +The search stops +when the distance between the tightest upper bound and the tightest lower bound +is smaller than a user-configured value, called Goal Width from now on. +In other words, the interval width at the end of the search +has to be no larger than the Goal Width. + +This Goal Width value therefore determines the precision of the result. +Due to the fact that MLRsearch specification requires a particular +structure of the result (see [Trial Result] (#Trial-Result) section), +the result itself does contain enough information to determine its +precision, thus it is not required to report the Goal Width value. + +This allows MLRsearch implementations to use stopping conditions +different from Goal Width. + +## Load Classification + +MLRsearch keeps the basic logic of binary search (tracking tightest bounds, +measuring at the middle), perhaps with minor technical differences. + +MLRsearch algorithm chooses an intended load (as opposed to the offered load), +the interval between bounds does not need to be split +exactly into two equal halves, +and the final reported structure specifies both bounds. + +The biggest difference is that to classify a load +as an upper or lower bound, MLRsearch may need more than one trial +(depending on configuration options) to be performed at the same intended load. + +In consequence, even if a load already does have few trial results, +it still may be classified as undecided, neither a lower bound nor an upper bound. + +An explanation of the classification logic is given in the next section [Logic of Load Classification] (#Logic-of-Load-Classification), +as it heavily relies on other subsections of this section. + +For repeatability and comparability reasons, it is important that +given a set of trial results, all implementations of MLRsearch +classify the load equivalently. + +## Loss Ratios + +Another difference between MLRsearch and [RFC2544] binary search is in the goals of the search. +[RFC2544] has a single goal, +based on classifying full-length trials as either lossless or lossy. + +MLRsearch, as the name suggests, can search for multiple goals, +differing in their loss ratios. +The precise definition of the Goal Loss Ratio will be given later. +The [RFC2544] throughput goal then simply becomes a zero Goal Loss Ratio. +Different goals also may have different Goal Widths. + +A set of trial results for one specific intended load value +can classify the load as an upper bound for some goals, but a lower bound +for some other goals, and undecided for the rest of the goals. + +Therefore, the load classification depends not only on trial results, +but also on the goal. +The overall search procedure becomes more complicated, when +compared to binary search with a single goal, +but most of the complications do not affect the final result, +except for one phenomenon, loss inversion. + +## Loss Inversion + +In [RFC2544] throughput search using bisection, any load with a lossy trial +becomes a hard upper bound, meaning every subsequent trial has a smaller +intended load. + +But in MLRsearch, a load that is classified as an upper bound for one goal +may still be a lower bound for another goal, and due to the other goal +MLRsearch will probably perform trials at even higher loads. +What to do when all such higher load trials happen to have zero loss? +Does it mean the earlier upper bound was not real? +Does it mean the later lossless trials are not considered a lower bound? +Surely we do not want to have an upper bound at a load smaller than a lower bound. + +MLRsearch is conservative in these situations. +The upper bound is considered real, and the lossless trials at higher loads +are considered to be a coincidence, at least when computing the final result. + +This is formalized using new notions, the [Relevant Upper Bound] (#Relevant-Upper-Bound) and +the [Relevant Lower Bound] (#Relevant-Lower-Bound). +Load classification is still based just on the set of trial results +at a given intended load (trials at other loads are ignored), +making it possible to have a lower load classified as an upper bound, +and a higher load classified as a lower bound (for the same goal). +The Relevant Upper Bound (for a goal) is the smallest load classified +as an upper bound. +But the Relevant Lower Bound is not simply +the largest among lower bounds. +It is the largest load among loads +that are lower bounds while also being smaller than the Relevant Upper Bound. + +With these definitions, the Relevant Lower Bound is always smaller +than the Relevant Upper Bound (if both exist), and the two relevant bounds +are used analogously as the two tightest bounds in the binary search. +When they are less than the Goal Width apart, +the relevant bounds are used in the output. + +One consequence is that every trial result can have an impact on the search result. +That means if your SUT (or your traffic generator) needs a warmup, +be sure to warm it up before starting the search. + +## Exceed Ratio + +The idea of performing multiple trials at the same load comes from +a model where some trial results (those with high loss) are affected +by infrequent effects, causing poor repeatability of [RFC2544] throughput results. +See the discussion about noiseful and noiseless ends +of the SUT performance spectrum in section [DUT in SUT] (#DUT-in-SUT). +Stable results are closer to the noiseless end of the SUT performance spectrum, +so MLRsearch may need to allow some frequency of high-loss trials +to ignore the rare but big effects near the noiseful end. + +MLRsearch can do such trial result filtering, but it needs +a configuration option to tell it how frequent can the infrequent big loss be. +This option is called the exceed ratio. +It tells MLRsearch what ratio of trials +(more exactly what ratio of trial seconds) can have a [Trial Loss Ratio] (#Trial-Loss-Ratio) +larger than the Goal Loss Ratio and still be classified as a lower bound. +Zero exceed ratio means all trials have to have a Trial Loss Ratio +equal to or smaller than the Goal Loss Ratio. + +For explainability reasons, the RECOMMENDED value for exceed ratio is 0.5, +as it simplifies some later concepts by relating them to the concept of median. + +## Duration Sum + +When more than one trial is intended to classify a load, +MLRsearch also needs something that controls the number of trials needed. +Therefore, each goal also has an attribute called duration sum. + +The meaning of a [Goal Duration Sum] (#Goal-Duration-Sum) is that +when a load has (full-length) trials +whose trial durations when summed up give a value at least as big +as the Goal Duration Sum value, +the load is guaranteed to be classified either as an upper bound +or a lower bound for that goal. + +Due to the fact that the duration sum has a big impact +on the overall search duration, and [RFC2544] prescribes +wait intervals around trial traffic, +the MLRsearch algorithm is allowed to sum durations that are different +from the actual trial traffic durations. + +In the MLRsearch specification, the different duration values are called +[Trial Effective Duration] (#Trial-Effective-Duration). + +## Short Trials + +MLRsearch requires each goal to specify its final trial duration. +Full-length trial is a shorter name for a trial whose intended trial duration +is equal to (or longer than) the goal final trial duration. + +Section 24 of [RFC2544] already anticipates possible time savings +when short trials (shorter than full-length trials) are used. +Full-length trials are the opposite of short trials, +so they may also be called long trials. + +Any MLRsearch implementation may include its own configuration options +which control when and how MLRsearch chooses to use short trial durations. + +For explainability reasons, when exceed ratio of 0.5 is used, +it is recommended for the Goal Duration Sum to be an odd multiple +of the full trial durations, so Conditional Throughput becomes identical to +a median of a particular set of trial forwarding rates. + +The presence of short trial results complicates the load classification logic. + +Full details are given later in section [Logic of Load Classification] (#Logic-of-Load-Classification). +In a nutshell, results from short trials +may cause a load to be classified as an upper bound. +This may cause loss inversion, and thus lower the Relevant Lower Bound, +below what would classification say when considering full-length trials only. + +{::comment} + [I still think this is important, revisit after explanations re quantiles.] + + <mark>For explainability reasons, it is RECOMMENDED users use such configurations + that guarantee all trials have the same length.</mark> + + <mark>mk edit note: Using RFC2119 keyword here does not seem to be + appropriate. Moreover, I do not get the meaning nor the logic behind + this statement. It seems to say that in order for users to understand + the workings of MLRsearch, they should use simplified configuration, + otherwise they won't get it. Illogical it seems to me. Suggest to + remove it.</mark> + +{:/comment} + +{::comment} + [Important. Keeping compatibility slows search considerably.] + + <mark>Alas, such configurations are usually not compliant with [RFC2544] requirements, + or not time-saving enough.</mark> + + <mark>mk edit note: This statement does not make sense to me. Suggest to remove it.</mark> + +{:/comment} + +## Throughput + +{::comment} + [Important, we need better title.] + + <mark>[VP] TODO: Was named Conditional Troughput, but spec chapter already has one.</mark> + +{:/comment} + +Due to the fact that testing equipment takes the intended load as an input parameter +for a trial measurement, any load search algorithm needs to deal +with intended load values internally. + +But in the presence of goals with a non-zero loss ratio, the intended load +usually does not match the user's intuition of what a throughput is. +The forwarding rate (as defined in [RFC2285] section 3.6.1) is better, +but it is not obvious how to generalize it +for loads with multiple trial results and a non-zero +[Goal Loss Ratio] (#Goal-Loss-Ratio). + +The best example is also the main motivation: hard limit performance. +Even if the medium allows higher performance, +the SUT interfaces may have their additional own limitations, +e.g. a specific fps limit on the NIC (a very common occurance). + +Ideally, those should be known and used when computing Max Load. +But if Max Load is higher that what interface can receive or transmit, +there will be a "hard limit" observed in trial results. +Imagine the hard limit is at 100 Mfps, Max Load is higher, +and the goal loss ratio is 0.5%. If DUT has no additional losses, +0.5% loss ratio will be achieved at 100.5025 Mfps (the relevant lower bound). +But it is not intuitive to report SUT performance as a value that is +larger than known hard limit. +We need a generalization of RFC2544 throughput, +different from just the relevant lower bound. + +MLRsearch defines one such generalization, called the Conditional Throughput. +It is the trial forwarding rate from one of the trials +performed at the load in question. +Determining which trial exactly is defined in +[MLRsearch Specification] (#MLRsearch-Specification), +and in [Appendix B: Conditional Throughput] (#Appendix-B\:-Conditional-Throughput). + +In the hard limit example, 100.5 Mfps load will still have +only 100.0 Mfps forwarding rate, nicely confirming the known limitation. + +Conditional Throughput is partially related to load classification. +If a load is classified as a lower bound for a goal, +the Conditional Throughput can be calculated from trial results, +and guaranteed to show an loss ratio +no larger than the Goal Loss Ratio. + +{::comment} + [Revisit after other edits, may be addressed elsewhere.] + + <mark>While the Conditional Throughput gives more intuitive-looking + values than the Relevant Lower Bound (for non-zero Goal Loss Ratio + values), the actual definition is more complicated than the definition + of the Relevant Lower Bound.</mark> + + <mark>mk edit note: Looking at this again, and per improved text, I + don't think it is that complicated. (BTW saying it is more complicated + and not addressing it, and leaving it open ended is not + good.) "Conditional throughput" intuitively is really throughput under + certain conditions, these being offered load determined by Relevant + Lower Bound and actual loss. For comparability, and taking into account + multiple trial samples, per MLRsearch definition, this is + mathematically expressed as `conditional_throughput = intended_load * + (1.0 - quantile_loss_ratio)`.</mark> + + <mark>DONE VP to MK: Hmm. Frequently, Conditional Throughput comes + from the worst among low-loss full-length trials. + But if two disparate goals are interested at the same load, + things get complicated (does not happen in CSIT production, + but I found few bugs when testing in simulator). + Computation in load classification is also not trivial, + but at least it only needs two "duration sum" values, + no need to sort all trial results.</mark> + + <mark>MKP2 [VP] TODO: Still not sure what to do with this subsection. + Possibly a bigger rewrite once VP and MK agree on what is (or is not) + complicated. :)</mark> + +{:/comment} + +{::comment} + [Important only for "design principles" chapter we may never have.] + + <mark>In the future, other intuitive values may become popular, + but they are unlikely to supersede the definition of the Relevant Lower Bound + as the most fitting value for comparability purposes, + therefore the Relevant Lower Bound remains a required attribute + of the Goal Result structure, while the Conditional Throughput is only optional.</mark> + + <mark>mk edit note: This paragraph adds to the confusion. I would remove + this paragraph, as with the new text above it doesn't seem to add any + value.</mark> + + <mark>[VP] TODO: This is an example of MLRsearch design principles.</mark> + +{:/comment} + +{::comment} + [Useful.] + + <mark>[VP] TODO: Mention somewhere that trending is a specific case + of repeatability/comparability.</mark> + +{:/comment} + +Note that when comparing the best (all zero loss) and worst case (all loss +just below Goal Loss Ratio), the same Relevant Lower Bound value +may result in the Conditional Throughput differing up to the Goal Loss Ratio. + +Therefore it is rarely needed to set the Goal Width (if expressed +as the relative difference of loads) below the Goal Loss Ratio. +In other words, setting the Goal Width below the Goal Loss Ratio +may cause the Conditional Throughput for a larger loss ratio to become smaller +than a Conditional Throughput for a goal with a smaller Goal Loss Ratio, +which is counter-intuitive, considering they come from the same search. +Therefore it is RECOMMENDED to set the Goal Width to a value no smaller +than the Goal Loss Ratio. + +Overall, this Conditional Throughput does behave well for comparability purposes. + +## Search Time + +MLRsearch was primarily developed to reduce the time +required to determine a throughput, either the [RFC2544] compliant one, +or some generalization thereof. +The art of achieving short search times +is mainly in the smart selection of intended loads (and intended durations) +for the next trial to perform. + +While there is an indirect impact of the load selection on the reported values, +in practice such impact tends to be small, +even for SUTs with quite a broad performance spectrum. + +A typical example of two approaches to load selection leading to different +Relevant Lower Bounds is when the interval is split in a very uneven way. +Any implementation choosing loads very close to the current Relevant Lower Bound +is quite likely to eventually stumble upon a trial result +with poor performance (due to SUT noise). +For an implementation choosing loads very close +to the current Relevant Upper Bound, this is unlikely, +as it examines more loads that can see a performance +close to the noiseless end of the SUT performance spectrum. + +However, as even splits optimize search duration at give precision, +MLRsearch implementations that prioritize minimizing search time +are unlikely to suffer from any such bias. + +Therefore, this document remains quite vague on load selection +and other optimization details, and configuration attributes related to them. +Assuming users prefer libraries that achieve short overall search time, +the definition of the Relevant Lower Bound +should be strict enough to ensure result repeatability +and comparability between different implementations, +while not restricting future implementations much. + +{::comment} + [Important for BMWG. Configurability is bad for comparability.] + + <mark>MKP2 Sadly, different implementations may exhibit their sweet spot of</mark> + <mark>the best repeatability for a given search duration</mark> + <mark>at different goals attribute values, especially concerning</mark> + <mark>any optional goal attributes such as the initial trial duration.</mark> + <mark>Thus, this document does not comment much on which configurations</mark> + <mark>are good for comparability between different implementations.</mark> + <mark>For comparability between different SUTs using the same implementation,</mark> + <mark>refer to configurations recommended by that particular implementation.</mark> + + <mark>MKP2 mk edit note: Isn't this going off on a tangent, hypothesising and + second guessing about different possible implementations. What is the + value of this content to this document? Suggest to remove it.</mark> + +{:/comment} + +## [RFC2544] Compliance + +Some Search Goal instances lead to results compliant with RFC2544. +See [RFC2544 Goal] (#RFC2544-Goal) for more details +regarding both conditional and unconditional compliance. + +The presence of other Search Goals does not affect the compliance +of this Goal Result. +The Relevant Lower Bound and the Conditional Throughput are in this case +equal to each other, and the value is the [RFC2544] throughput. + +# Logic of Load Classification + +## Introductory Remarks + +This chapter continues with explanations, +but this time more precise definitions are needed +for readers to follow the explanations. + +Descriptions in this section are wordy and implementers should read +[MLRsearch Specification] (#MLRsearch-Specification) section +and Appendices for more concise definitions. + +The two areas of focus here are load classification +and the Conditional Throughput. + +To start with [Performance Spectrum] (#Performance-Spectrum) +subsection contains definitions needed to gain insight +into what Conditional Throughput means. +Remaining subsections discuss load classification. + +For load classification, it is useful to define **good trials** and **bad trials**: + +- **Bad trial**: Trial is called bad (according to a goal) + if its [Trial Loss Ratio] (#Trial-Loss-Ratio) + is larger than the [Goal Loss Ratio] (#Goal-Loss-Ratio). + +- **Good trial**: Trial that is not bad is called good. + +## Performance Spectrum +### Description + +There are several equivalent ways to explain the Conditional Throughput +computation. One of the ways relies on performance +spectrum. + +Take an intended load value, a trial duration value, and a finite set +of trial results, with all trials measured at that load value and duration value. + +The performance spectrum is the function that maps +any non-negative real number into a sum of trial durations among all trials +in the set, that has that number, as their trial forwarding rate, +e.g. map to zero if no trial has that particular forwarding rate. + +A related function, defined if there is at least one trial in the set, +is the performance spectrum divided by the sum of the durations +of all trials in the set. + +That function is called the performance probability function, as it satisfies +all the requirements for probability mass function +of a discrete probability distribution, +the one-dimensional random variable being the trial forwarding rate. + +These functions are related to the SUT performance spectrum, +as sampled by the trials in the set. + +{::comment} + [Middle of rewrite?] + + <mark>MKP1 The performance spectrum is the function that maps + any non-negative real number into a sum of trial durations among all trials + in the set, that has that number, as their trial forwarding rate, + e.g. map to zero if no trial has that particular forwarding rate.</mark> + + <mark>MKP1 A related function, defined if there is at least one trial in the set, + is the performance spectrum divided by the sum of the durations + of all trials in the set.</mark> + + <mark>MKP1 That function is called the performance probability function, as it satisfies + all the requirements for probability mass function + of a discrete probability distribution, + the one-dimensional random variable being the trial forwarding rate.</mark> + + <mark>MKP1 These functions are related to the SUT performance spectrum, + as sampled by the trials in the set.</mark> + + <mark>MKP1 [VP] TODO: Introduce quantiles properly by incorporating the below.</mark> + + <mark>MKP1 [VP] TODO: "q-quantile" is plainly wrong. I meant the "p" in "p-quantile". + + - wikipedia: The 100-quantiles are called percentiles + - also wiki: If, instead of using integers k and q, the "p-quantile" is based on a real number p with 0 < p < 1 then... + - https://en.wikipedia.org/wiki/Quantile_function + - exceed ratio is an input to a quantile function: percentage? + </mark> + + <mark>MKP1 mk2 TODO for VP: Above is not making it clearer at all. Can't we really not explain the spectrum and exceed ratio with just percentiles and quantiles?</mark> + + As for any other probability function, we can talk about percentiles + of the performance probability function, including the median. + The Conditional Throughput will be one such quantile value + for a specifically chosen set of trials. + + <mark>MKP2 As for any other probability function, we can talk about percentiles + of the performance probability function, including the median. + The Conditional Throughput will be one such quantile value + for a specifically chosen set of trials.</mark> + +{:/comment} + +Take a set of all full-length trials performed at the Relevant Lower Bound, +sorted by decreasing trial forwarding rate. +The sum of the durations of those trials +may be less than the Goal Duration Sum, or not. +If it is less, add an imaginary trial result with zero trial forwarding rate, +such that the new sum of durations is equal to the Goal Duration Sum. +This is the set of trials to use. + +If the quantile touches two trials, + +{::comment} + [Clarity.] + + <mark>mk edit note: What does it mean "quantile touches two trials"? + Do you mean two trials are within specific quantile or percentile?</mark> + +{:/comment} + +the larger trial forwarding rate (from the trial result sorted earlier) is used. + +{::comment} + [Oh, unspecified exceed ratio?] + + <mark>the larger trial forwarding rate (from the trial result sorted earlier) is used.</mark> + + <mark>mk edit note: Why is that? Is it because you silently assumed that + quantile here is median or 50th percentile?</mark> + +{:/comment} + +The resulting quantity is the Conditional Throughput of the goal in question. + +{::comment} + [Motivation has lead to code. Now code is definition, this should be equivalent.] + + <mark>The resulting quantity is the Conditional Throughput of the goal in question.</mark> + + <mark>mk edit note: Is this is supposed to be another definition of + Conditional Throughput? If so, how does this relate to Performance + Spectrum? I suggest to either remove these unclear paragraphs above and + rely on examples below that are clear, or rework above so it fits the + flow. Cause right now it's confusion. Even more so, that + [Conditional Throughput] (#Conditional-Throughput) has been already + defined elsewhere in the document.</mark> + +{:/comment} + +A set of examples follows. + +### First Example + +- [Goal Exceed Ratio] (#Goal-Exceed-Ratio) = 0 and [Goal Duration Sum] (#Goal-Duration-Sum) has been reached. +- Conditional Throughput is the smallest trial forwarding rate among the trials. + +### Second Example + +- Goal Exceed Ratio = 0 and Goal Duration Sum has not been reached yet. +- Due to the missing duration sum, the worst case may still happen, so the Conditional Throughput is zero. +- This is not reported to the user, as this load cannot become the Relevant Lower Bound yet. + +### Third Example + +- Goal Exceed Ratio = 50% and Goal Duration Sum is two seconds. +- One trial is present with the duration of one second and zero loss. +- The imaginary trial is added with the duration of one second and zero trial forwarding rate. +- The median would touch both trials, so the Conditional Throughput is the trial forwarding rate of the one non-imaginary trial. +- As that had zero loss, the value is equal to the offered load. + +{::comment} + [Middle of rewrite?] + + <mark>MKP2 mk edit note: how is the median "touching" both trials? + Isn't median of even set of data samples + the average of the two middle data points, + in this case the non-imaginary trial and the imaginary one?</mark> + + <mark>MKP2 Note that Appendix B does not take into account short trial results.</mark> + + <mark>MKP2 mk edit note: Whis is this relevant here? Appendix B has not been mentioned in this section.</mark> + +{:/comment} + +### Summary + +While the Conditional Throughput is a generalization of the trial forwarding rate, +its definition is not an obvious one. + +Other than the trial forwarding rate, the other source of intuition +is the quantile in general, and the median the recommended case. + +{::comment} + [Next version of MLRsearch library may invent new quantity that is more stable.] + + <mark>In future, different quantities may prove more useful, + especially when applying to specific problems, + but currently the Conditional Throughput is the recommended compromise, + especially for repeatability and comparability reasons.</mark> + + <mark>MKP2 mk edit note: This is future looking and hand wavy without + specifics. What are the "specific problems" that are referred here? + Networking, else?Some specific behaviours, if so, what sort? If + something is classified as future work, it needs to be better defined. + The same applies to any out of scope statements.</mark> + +{:/comment} + +## Trials with Single Duration + +{::comment} + [Clarity.] + + <mark>MKP2 mk edit note: Need to improve explanations in this subsection.</mark> + +{:/comment} + +When goal attributes are chosen in such a way that every trial has the same +intended duration, the load classification is simpler. + +The following description follows the motivation +of Goal Loss Ratio, Goal Exceed Ratio, and Goal Duration Sum. + +If the sum of the durations of all trials (at the given load) +is less than the Goal Duration Sum, imagine two scenarios: + +- **best case scenario**: all subsequent trials having zero loss, and +- **worst case scenario**: all subsequent trials having 100% loss. + +Here we assume there are as many subsequent trials as needed +to make the sum of all trials equal to the Goal Duration Sum. + +The exceed ratio is defined using sums of durations +(and number of trials does not matter), so it does not matter whether +the "subsequent trials" can consist of an integer number of full-length trials. + +In any of the two scenarios, best case and worst case, we can compute the load exceed ratio, +as the duration sum of good trials divided by the duration sum of all trials, +in both cases including the assumed trials. + +Even if, in the best case scenario, the load exceed ratio is larger +than the Goal Exceed Ratio, the load is an upper bound. + +MKP2 Even if, in the worst case scenario, the load exceed ratio is not larger +than the Goal Exceed Ratio, the load is a lower bound. + +{::comment} + [Middle of rewrite?] + + <mark>Even if</mark>, in the best case scenario, the load exceed ratio is larger + than the Goal Exceed Ratio, the load is an upper bound. + + <mark>MKP2 Even if</mark>, in the worst case scenario, the load exceed ratio is not larger + than the Goal Exceed Ratio, the load is a lower bound. + + <mark>MKP2 mk edit note: I am confused by "Even if" prefixing + each of the above statements. And even more so by your version + with "If even".</mark> + + <mark>mk edit note: I do not get how this statements are true, as they + are counter-intuitive. For the best case scenario, if load exceed ratio + is larger than the goal exceed ratio, I expect the load to be lower + bound. Need more examples.</mark> + +{:/comment} + +More specifically: + +- Take all trials measured at a given load. +- The sum of the durations of all bad full-length trials is called the bad sum. +- The sum of the durations of all good full-length trials is called the good sum. +- The result of adding the bad sum plus the good sum is called the measured sum. +- The larger of the measured sum and the Goal Duration Sum is called the whole sum. +- The whole sum minus the measured sum is called the missing sum. +- The optimistic exceed ratio is the bad sum divided by the whole sum. +- The pessimistic exceed ratio is the bad sum plus the missing sum, that divided by the whole sum. +- If the optimistic exceed ratio is larger than the Goal Exceed Ratio, the load is classified as an upper bound. +- If the pessimistic exceed ratio is not larger than the Goal Exceed Ratio, the load is classified as a lower bound. +- Else, the load is classified as undecided. + +The definition of pessimistic exceed ratio is compatible with the logic in +the Conditional Throughput computation, so in this single trial duration case, +a load is a lower bound if and only if the Conditional Throughput +loss ratio is not larger than the Goal Loss Ratio. + +{::comment} + [Useful (depends on the whole chapter).] + + <mark>MKP2 mk edit note: I do not get the defintion of optimistic and + pessmistic exceed ratios. Please define or describe what they + are.</mark> + +{:/comment} + +If it is larger, the load is either an upper bound or undecided. + +## Trials with Short Duration + +### Scenarios + +Trials with intended duration smaller than the goal final trial duration +are called short trials. +The motivation for load classification logic in the presence of short trials +is based around a counter-factual case: What would the trial result be +if a short trial has been measured as a full-length trial instead? + +There are three main scenarios where human intuition guides +the intended behavior of load classification. + +#### False Good Scenario + +The user had their reason for not configuring a shorter goal +final trial duration. +Perhaps SUT has buffers that may get full at longer +trial durations. +Perhaps SUT shows periodic decreases in performance +the user does not want to be treated as noise. + +In any case, many good short trials may become bad full-length trials +in the counter-factual case. + +In extreme cases, there are plenty of good short trials and no bad short trials. + +In this scenario, we want the load classification NOT to classify the load +as a lower bound, despite the abundance of good short trials. + +{::comment} + [I agree.] + + <mark>MKP2 mk edit note: It may be worth adding why that is. i.e. because + there is a risk that at longer trial this could turn into a bad + trial.</mark> + +{:/comment} + +Effectively, we want the good short trials to be ignored, so they +do not contribute to comparisons with the Goal Duration Sum. + +#### True Bad Scenario + +When there is a frame loss in a short trial, +the counter-factual full-length trial is expected to lose at least as many +frames. + +In practice, bad short trials are rarely turning into +good full-length trials. + +In extreme cases, there are no good short trials. + +In this scenario, we want the load classification +to classify the load as an upper bound just based on the abundance +of short bad trials. + +Effectively, we want the bad short trials +to contribute to comparisons with the Goal Duration Sum, +so the load can be classified sooner. + +#### Balanced Scenario + +Some SUTs are quite indifferent to trial duration. +Performance probability function constructed from short trial results +is likely to be similar to the performance probability function constructed +from full-length trial results (perhaps with larger dispersion, +but without a big impact on the median quantiles overall). + +{::comment} + [Recheck after edits earlier.] + + <mark>MKP1 mk edit note: "Performance probability function" is this function + defined anywhere? Mention in [Performance Spectrum] (#Performance Spectrum) + is not a complete definition.</mark> + +{:/comment} + +For a moderate Goal Exceed Ratio value, this may mean there are both +good short trials and bad short trials. + +This scenario is there just to invalidate a simple heuristic +of always ignoring good short trials and never ignoring bad short trials, +as that simple heuristic would be too biased. + +Yes, the short bad trials +are likely to turn into full-length bad trials in the counter-factual case, +but there is no information on what would the good short trials turn into. + +The only way to decide safely is to do more trials at full length, +the same as in False Good Scenario. + +### Classification Logic + +MLRsearch picks a particular logic for load classification +in the presence of short trials, but it is still RECOMMENDED +to use configurations that imply no short trials, +so the possible inefficiencies in that logic +do not affect the result, and the result has better explainability. + +With that said, the logic differs from the single trial duration case +only in different definition of the bad sum. +The good sum is still the sum across all good full-length trials. + +Few more notions are needed for defining the new bad sum: + +- The sum of durations of all bad full-length trials is called the bad long sum. +- The sum of durations of all bad short trials is called the bad short sum. +- The sum of durations of all good short trials is called the good short sum. +- One minus the Goal Exceed Ratio is called the subceed ratio. +- The Goal Exceed Ratio divided by the subceed ratio is called the exceed coefficient. +- The good short sum multiplied by the exceed coefficient is called the balancing sum. +- The bad short sum minus the balancing sum is called the excess sum. +- If the excess sum is negative, the bad sum is equal to the bad long sum. +- Otherwise, the bad sum is equal to the bad long sum plus the excess sum. + +Here is how the new definition of the bad sum fares in the three scenarios, +where the load is close to what would the relevant bounds be +if only full-length trials were used for the search. + +#### False Good Scenario + +If the duration is too short, we expect to see a higher frequency +of good short trials. +This could lead to a negative excess sum, +which has no impact, hence the load classification is given just by +full-length trials. +Thus, MLRsearch using too short trials has no detrimental effect +on result comparability in this scenario. +But also using short trials does not help with overall search duration, +probably making it worse. + +#### True Bad Scenario + +Settings with a small exceed ratio +have a small exceed coefficient, so the impact of the good short sum is small, +and the bad short sum is almost wholly converted into excess sum, +thus bad short trials have almost as big an impact as full-length bad trials. +The same conclusion applies to moderate exceed ratio values +when the good short sum is small. +Thus, short trials can cause a load to get classified as an upper bound earlier, +bringing time savings (while not affecting comparability). + +#### Balanced Scenario + +Here excess sum is small in absolute value, as the balancing sum +is expected to be similar to the bad short sum. +Once again, full-length trials are needed for final load classification; +but usage of short trials probably means MLRsearch needed +a shorter overall search time before selecting this load for measurement, +thus bringing time savings (while not affecting comparability). + +Note that in presence of short trial results, +the comparibility between the load classification +and the Conditional Throughput is only partial. +The Conditional Throughput still comes from a good long trial, +but a load higher than the Relevant Lower Bound may also compute to a good value. + +## Trials with Longer Duration + +If there are trial results with an intended duration larger +than the goal trial duration, the precise definitions +in Appendix A and Appendix B treat them in exactly the same way +as trials with duration equal to the goal trial duration. + +But in configurations with moderate (including 0.5) or small +Goal Exceed Ratio and small Goal Loss Ratio (especially zero), +bad trials with longer than goal durations may bias the search +towards the lower load values, as the noiseful end of the spectrum +gets a larger probability of causing the loss within the longer trials. + +{::comment} + [Use single goal when testing externaly, deviate freely in internal tests.] + + <mark>For some users, this is an acceptable price</mark> + <mark>for increased configuration flexibility</mark> + <mark>(perhaps saving time for the related goals),</mark> + <mark>so implementations SHOULD allow such configurations.</mark> + <mark>Still, users are encouraged to avoid such configurations</mark> + <mark>by making all goals use the same final trial duration,</mark> + <mark>so their results remain comparable across implementations.</mark> + + <mark>MKP2 mk edit note: This paragraph has no value in my view. + Statements like "For some users, this is an acceptable price + for increased configuration flexibility" do not make sense. + Configuration flexibility for flexibility sake is not a valid argument + in the specification that aims at standardising benchmarking methodologies. + If one wants to test with longer durations, + then one should configure these as Goal Final Trial Duration. + Simple, no? Or am I reading this point wrong?</mark> + +{:/comment} + +{::comment} + [MKP4 Out of scope here, subject for future work] + + # Current practices? + + <mark>MKP2 [VP] TODO: Even if not mentioned in spec (not even recommended), + some tricks from CSIT code may be worth mentioning? Not sure.</mark> + + <mark>MKP2 [VP] TODO: Tricks with big impact on search time + can be mentioned so that Addressed Problems : Long Test Duration + has something specific to refer to.</mark> + + <mark>MKP2 [VP] TODO: It is important to mention trick that have impact + on repeatability and comparability.</mark> + + <mark>MKP2 [VP] TODO: CSIT computes a discrete "grid" of load values to use.</mark> + + <mark>MKP2 [VP] TODO: + If all Goal Widths are aligned, there is one common coarse grid. + In that case, NDR (and even PDR conditional throughput + for tests with zer-or-big losses) values are identical in trending, + hiding the real performance variance, and causing fake anomaly + when the performance shifts just one gridpoint. + </mark> + + <mark>MKP2 [VP] TODO: Conversely, when Goal Width do not match well, + CSIT needs to compute a fine-grained grid to match them all. + In this case, similar performances can be "rounded differently", + mostly based on specific loss that happened at Max Load, + where SUT may be less stable than around PDR. + This way trending sees higher variance (still within corresponding Goal Width), + but at least there are no fake anomalies. + </mark> + + <mark>MKP2 [VP] TODO: In general, do not trust stdev if not larged than width.</mark> + + <mark>MKP2 [VP] TODO: De we have a chapter section fosucing on design principles? + - Make Controller API independent from Measurer API. + - The "allowed if makes worse" principle: + - RFC1242 specmanship happens when testing own DUTs. + - Shortening trial wait times only risks making goal results lower. + - So it is fine to save time aggressively when testing own DUTs. + </mark> + +{:/comment} + + +{::comment} + [Will be nice if made substantial.] + + # Addressed Problems + + <mark>MKP1 all of this section requires updating based on the updated content. + And it is for information only anyways. In fact not sure it's needed. + Maybe in appendix for posterity.</mark> + + Now when MLRsearch is clearly specified and explained, + it is possible to summarize how does MLRsearch specification help with problems. + + Here, "multiple trials" is a shorthand for having the goal final trial duration + significantly smaller than the Goal Duration Sum. + This results in MLRsearch performing multiple trials at the same load, + which may not be the case with other configurations. + + ## Long Test Duration + + As shortening the overall search duration is the main motivation + of MLRsearch library development, the library implements + multiple improvements on this front, both big and small. + + Most of implementation details are not constrained by MLRsearch specification, + so that future implementations may keep shortening the search duration even more. + + One exception is the impact of short trial results on the Relevant Lower Bound. + While motivated by human intuition, the logic is not straightforward. + In practice, configurations with only one common trial duration value + are capable of achieving good overal search time and result repeatability + without the need to consider short trials. + + ### Impact of goal attribute values + + From the required goal attributes, the Goal Duration Sum + remains the best way to get even shorter searches. + + Usage of multiple trials can also save time, + depending on wait times around trial traffic. + + The farther the Goal Exceed Ratio is from 0.5 (towards zero or one), + the less predictable the overal search duration becomes in practice. + + Width parameter does not change search duration much in practice + (compared to other, mainly optional goal attributes). + + ## DUT in SUT + + In practice, using multiple trials and moderate exceed ratios + often improves result repeatability without increasing the overall search time, + depending on the specific SUT and DUT characteristics. + Benefits for separating SUT noise are less clear though, + as it is not easy to distinguish SUT noise from DUT instability in general. + + Conditional Throughput has an intuitive meaning when described + using the performance spectrum, so this is an improvement + over existing simple (less configurable) search procedures. + + Multiple trials can save time also when the noisy end of + the preformance spectrum needs to be examined, e.g. for [RFC9004]. + + Under some circumstances, testing the same DUT and SUT setup with different + DUT configurations can give some hints on what part of noise is SUT noise + and what part is DUT performance fluctuations. + In practice, both types of noise tend to be too complicated for that analysis. + + MLRsearch enables users to search for multiple goals, + potentially providing more insight at the cost of a longer overall search time. + However, for a thorough and reliable examination of DUT-SUT interactions, + it is necessary to employ additional methods beyond black-box benchmarking, + such as collecting and analyzing DUT and SUT telemetry. + + ## Repeatability and Comparability + + Multiple trials improve repeatability, depending on exceed ratio. + + In practice, one-second goal final trial duration with exceed ratio 0.5 + is good enough for modern SUTs. + However, unless smaller wait times around the traffic part of the trial + are allowed, too much of overal search time would be wasted on waiting. + + It is not clear whether exceed ratios higher than 0.5 are better + for repeatability. + The 0.5 value is still preferred due to explainability using median. + + It is possible that the Conditional Throughput values (with non-zero goal + loss ratio) are better for repeatability than the Relevant Lower Bound values. + This is especially for implementations + which pick load from a small set of discrete values, + as that hides small variances in Relevant Lower Bound values + other implementations may find. + + Implementations focusing on shortening the overall search time + are automatically forced to avoid comparability issues due to load selection, + as they must prefer even splits wherever possible. + But this conclusion only holds when the same goals are used. + Larger adoption is needed before any further claims on comparability + between MLRsearch implementations can be made. + + ## Throughput with Non-Zero Loss + + Trivially suported by the Goal Loss Ratio attribute. + + In practice, usage of non-zero loss ratio values + improves the result repeatability + (exactly as expected based on results from simpler search methods). + + ## Inconsistent Trial Results + + MLRsearch is conservative wherever possible. + This is built into the definition of Conditional Throughput, + and into the treatment of short trial results for load classification. + + This is consistent with [RFC2544] zero loss tolerance motivation. + + If the noiseless part of the SUT performance spectrum is of interest, + it should be enough to set small value for the goal final trial duration, + and perhaps also a large value for the Goal Exceed Ratio. + + Implementations may offer other (optional) configuration attributes + to become less conservative, but currently it is not clear + what impact would that have on repeatability. + +{:/comment} + +# IANA Considerations + +No requests of IANA. + +# Security Considerations + +Benchmarking activities as described in this memo are limited to +technology characterization of a DUT/SUT using controlled stimuli in a +laboratory environment, with dedicated address space and the constraints +specified in the sections above. + +The benchmarking network topology will be an independent test setup and +MUST NOT be connected to devices that may forward the test traffic into +a production network or misroute traffic to the test management network. + +Further, benchmarking is performed on a "black-box" basis, relying +solely on measurements observable external to the DUT/SUT. + +Special capabilities SHOULD NOT exist in the DUT/SUT specifically for +benchmarking purposes. Any implications for network security arising +from the DUT/SUT SHOULD be identical in the lab and in production +networks. + +# Acknowledgements + +Some phrases and statements in this document were created +with help of Mistral AI (mistral.ai). + +Many thanks to Alec Hothan of the OPNFV NFVbench project for thorough +review and numerous useful comments and suggestions in the earlier versions of this document. + +Special wholehearted gratitude and thanks to the late Al Morton for his +thorough reviews filled with very specific feedback and constructive +guidelines. Thank you Al for the close collaboration over the years, +for your continuous unwavering encouragement full of empathy and +positive attitude. Al, you are dearly missed. + +# Appendix A: Load Classification + +This section specifies how to perform the load classification. + +Any intended load value can be classified, according to a given [Search Goal] (#Search-Goal). + +The algorithm uses (some subsets of) the set of all available trial results +from trials measured at a given intended load at the end of the search. +All durations are those returned by the Measurer. + +The block at the end of this appendix holds pseudocode +which computes two values, stored in variables named +`optimistic` and `pessimistic`. + +{::comment} + [We have other section re optimistic. Not going to talk about variable naming here.] + + <mark>MKP2 mk edit note: Need to add the description of what + the `optimistic` and `pessimistic` variables represent. + Or a reference to where this is described + e.g. in [Single Trial Duration] (#Single-Trial-Duration) section.</mark> + +{:/comment} + +The pseudocode happens to be a valid Python code. + +If values of both variables are computed to be true, the load in question +is classified as a lower bound according to the given Search Goal. +If values of both variables are false, the load is classified as an upper bound. +Otherwise, the load is classified as undecided. + +The pseudocode expects the following variables to hold values as follows: + +- `goal_duration_sum`: The duration sum value of the given Search Goal. + +- `goal_exceed_ratio`: The exceed ratio value of the given Search Goal. + +- `good_long_sum`: Sum of durations across trials with trial duration + at least equal to the goal final trial duration and with a Trial Loss Ratio + not higher than the Goal Loss Ratio. + +- `bad_long_sum`: Sum of durations across trials with trial duration + at least equal to the goal final trial duration and with a Trial Loss Ratio + higher than the Goal Loss Ratio. + +- `good_short_sum`: Sum of durations across trials with trial duration + shorter than the goal final trial duration and with a Trial Loss Ratio + not higher than the Goal Loss Ratio. + +- `bad_short_sum`: Sum of durations across trials with trial duration + shorter than the goal final trial duration and with a Trial Loss Ratio + higher than the Goal Loss Ratio. + +The code works correctly also when there are no trial results at a given load. + +~~~ python +balancing_sum = good_short_sum * goal_exceed_ratio / (1.0 - goal_exceed_ratio) +effective_bad_sum = bad_long_sum + max(0.0, bad_short_sum - balancing_sum) +effective_whole_sum = max(good_long_sum + effective_bad_sum, goal_duration_sum) +quantile_duration_sum = effective_whole_sum * goal_exceed_ratio +optimistic = effective_bad_sum <= quantile_duration_sum +pessimistic = (effective_whole_sum - good_long_sum) <= quantile_duration_sum +~~~ + +# Appendix B: Conditional Throughput + +This section specifies how to compute Conditional Throughput, as referred to in section [Conditional Throughput] (#Conditional-Throughput). + +Any intended load value can be used as the basis for the following computation, +but only the Relevant Lower Bound (at the end of the search) +leads to the value called the Conditional Throughput for a given Search Goal. + +The algorithm uses (some subsets of) the set of all available trial results +from trials measured at a given intended load at the end of the search. +All durations are those returned by the Measurer. + +The block at the end of this appendix holds pseudocode +which computes a value stored as variable `conditional_throughput`. + +{::comment} + [CT is CT. But text could make more obvious.] + + <mark>MKP2 mk edit note: Need to add the description of what does + the `conditional_throughput` variable represent. + Or a reference to where this is described + e.g. in [Conditional Throughput] (#Conditional-Throughput) section.</mark> + +{:/comment} + +The pseudocode happens to be a valid Python code. + +The pseudocode expects the following variables to hold values as follows: + +- `goal_duration_sum`: The duration sum value of the given Search Goal. + +- `goal_exceed_ratio`: The exceed ratio value of the given Search Goal. + +- `good_long_sum`: Sum of durations across trials with trial duration + at least equal to the goal final trial duration and with a Trial Loss Ratio + not higher than the Goal Loss Ratio. + +- `bad_long_sum`: Sum of durations across trials with trial duration + at least equal to the goal final trial duration and with a Trial Loss Ratio + higher than the Goal Loss Ratio. + +- `long_trials`: An iterable of all trial results from trials with trial duration + at least equal to the goal final trial duration, + sorted by increasing the Trial Loss Ratio. + A trial result is a composite with the following two attributes available: + + - `trial.loss_ratio`: The Trial Loss Ratio as measured for this trial. + + - `trial.duration`: The trial duration of this trial. + +The code works correctly only when there if there is at least one +trial result measured at a given load. + +~~~ python +all_long_sum = max(goal_duration_sum, good_long_sum + bad_long_sum) +remaining = all_long_sum * (1.0 - goal_exceed_ratio) +quantile_loss_ratio = None +for trial in long_trials: + if quantile_loss_ratio is None or remaining > 0.0: + quantile_loss_ratio = trial.loss_ratio + remaining -= trial.duration + else: + break +else: + if remaining > 0.0: + quantile_loss_ratio = 1.0 +conditional_throughput = intended_load * (1.0 - quantile_loss_ratio) +~~~ + +--- back + +{::comment} + [Final checklist.] + + <mark>[VP] Final Checks. Only mark as done when there are no active todos above.</mark> + + <mark>[VP] Rename chapter/sub-/section to better match their content.</mark> + + <mark>MKP3 [VP] TODO: Recheck the definition dependencies go bottom-up.</mark> + + <mark>[VP] TODO: Unify external reference style (brackets, spaces, section numbers and names).</mark> + + <mark>[VP] TODO: Add internal links wherever Captialized Term is mentioned.</mark> + + <mark>MKP2 [VP] TODO: Capitalization of New Terms: useful when editing and reviewing, + but I still vote to remove capitalization before final submit, + because all other RFCs I see only capitalize due to being section title.</mark> + + <mark>[VP] TODO: If time permits, keep improving formal style (e.g. using AI).</mark> + +{:/comment} diff --git a/docs/ietf/process.txt b/docs/ietf/process.txt index 128c31bff1..6492861163 100644 --- a/docs/ietf/process.txt +++ b/docs/ietf/process.txt @@ -22,7 +22,7 @@ $ sudo gem install kramdown-rfc2629 $ kdrfc --version Main: -$ kdrfc draft-ietf-bmwg-mlrsearch-06.md +$ kdrfc draft-ietf-bmwg-mlrsearch-07.md If that complains, do it manually at https://author-tools.ietf.org/ diff --git a/docs/layouts/shortcodes/dashboard_url.html b/docs/layouts/shortcodes/dashboard_url.html new file mode 100644 index 0000000000..d0738797c2 --- /dev/null +++ b/docs/layouts/shortcodes/dashboard_url.html @@ -0,0 +1 @@ +{{ .Site.Data.variables.dashboard_url }}
\ No newline at end of file |