From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EF116A0C47; Sat, 18 Sep 2021 04:08:28 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BAA9E4014E; Sat, 18 Sep 2021 04:08:28 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id C8B704003D for ; Sat, 18 Sep 2021 04:08:26 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10110"; a="222955150" X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="222955150" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2021 19:08:25 -0700 X-IronPort-AV: E=Sophos;i="5.85,303,1624345200"; d="scan'208";a="510191179" Received: from unknown (HELO localhost.localdomain) ([10.240.183.163]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 17 Sep 2021 19:08:22 -0700 From: Yu Jiang To: dts@dpdk.org Cc: Yu Jiang Date: Sat, 18 Sep 2021 10:08:01 +0800 Message-Id: <1631930882-12140-1-git-send-email-yux.jiang@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [dts] [PATCH V1] test_plans/loadbalancer: remove example X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org Sender: "dts" According to DPDK commit id ab6ebd7020("examples/load_balancer: remove example"), remove this plan and suite. Signed-off-by: Yu Jiang --- test_plans/index.rst | 1 - test_plans/loadbalancer_test_plan.rst | 194 ---------------------------------- tests/TestSuite_loadbalancer.py | 154 --------------------------- 3 files changed, 349 deletions(-) delete mode 100644 test_plans/loadbalancer_test_plan.rst delete mode 100644 tests/TestSuite_loadbalancer.py diff --git a/test_plans/index.rst b/test_plans/index.rst index b5aaec5..d9dbc2a 100644 --- a/test_plans/index.rst +++ b/test_plans/index.rst @@ -179,7 +179,6 @@ The following are the test plans for the DPDK DTS automated test system. vxlan_test_plan af_xdp_test_plan l2fwd_jobstats_test_plan - loadbalancer_test_plan loopback_multi_queues_test_plan telemetry_test_plan compressdev_isal_pmd_test_plan diff --git a/test_plans/loadbalancer_test_plan.rst b/test_plans/loadbalancer_test_plan.rst deleted file mode 100644 index b5cc769..0000000 --- a/test_plans/loadbalancer_test_plan.rst +++ /dev/null @@ -1,194 +0,0 @@ -.. Copyright (c) <2011>, Intel Corporation - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - - Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - - Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - - - Neither the name of Intel Corporation nor the names of its - contributors may be used to endorse or promote products derived - from this software without specific prior written permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS - FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE - COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, - INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES - (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR - SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, - STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED - OF THE POSSIBILITY OF SUCH DAMAGE. - -============= -Load Balancer -============= - -This test case uses the Load Balancer sample application to benchmark the -concept of isolating the packet I/O task from the application specific workload. -A number of lcores are dedicated to handle the interaction with the NIC ports -(I/O lcores), while the rest of the lcores are dedicated to performing the -application processing (worker lcores). The worker lcores are totally oblivious -to the intricacies of the packet I/O activity and use the NIC-agnostic interface -provided by SW rings to exchange packets with the I/O cores. - -Prerequisites -============= - -1. Hardware requirements - -- For each CPU socket, each memory channel should be populated with at least - 1x DIMM. -- If the PCIe controller is on the CPU, then each CPU socket is populated with - the same number of NICs (2x or 4x NICs per CPU socket); -- Special PCIe restrictions may be required for performance. For example, the - following requirements should be met for 10GbE NICs: - - - NICs are plugged into PCIe Gen2 or Gen3 slots; - - For PCIe Gen2 slots, the number of lanes should be 8x or higher; - - A single port from each NIC card should be used, so for 4x ports, 4x NICs - should be connected to the traffic generator. - -2. BIOS requirements - -- Hyper-Threading Technology is ENABLED -- Hardware Prefetcher is DISABLED -- Adjacent Cache Line Prefetch is DISABLED -- Direct Cache Access is DISABLED - -3. Linux kernel requirements - -- Linux kernel has the following features enabled: huge page support, UIO, HPET -- Appropriate number of huge pages are reserved at kernel boot time -- The IDs of the hardware threads (logical cores) per each CPU socket can be - determined by parsing the file /proc/cpuinfo. The naming convention for the - logical cores is: C{x.y.z} = hyper-thread z of physical core y of CPU socket - x, with typical values of x = 0 .. 3, y = 0 .. 7, z = 0 .. 1. Logical cores - C{0.0.1} and C{0.0.1} should be avoided while executing the test, as they - are used by the Linux kernel for running regular processes. - -4. Software application configuration - -The application configuration is done through the command line: - -- -c COREMASK: Reunion of all the cores specified by the --rx, --tx and --w - parameters. -- --rx and --tx: These parameters are used to provide the list of lcores used - for packet I/O, plus the list of the RX ports & queues, as well as the list - of TX ports, that are handled by each of the packet I/O lcores; -- The RX and TX of the NICs that are physically attached (through PCIe) to a - specific CPU socket should always be handled by lcores from the same socket; -- The RX and TX of the same port can be handled by different lcores, depending - on the usecase, therefore the set of RX lcores can be different than the set - of TX lcores; -- Typical configurations enabled for the I/O cores for each CPU socket (as long - as the conditions below are met, the actual lcore IDs are irrelevant): - - - Single lcore handling the RX and TX for all the NICs connected to its CPU - socket. Its sibling hyper-thread should not be used by the application; - -- One lcore handling the RX and TX for a single NIC port (with its sibling - hyper-thread not used by the application). For each CPU socket, there are N - physical cores used for packet I/O for N NIC ports; -- One lcore handling the RX for all the NIC ports connected to its CPU socket - and another lcore handling the TX for the same NIC ports (with the sibling - hyper-threads not used by the application). For each CPU socket, there are 2 - physical cores used for packet I/O for N NIC ports; -- --w: This parameter specifies the list of worker lcores; - - - A worker lcore cannot be a packet I/O lcore; - - Typical configurations enabled for each CPU socket: 1 / 2 / 4 / 8. Each - worker should be allocated on a different physical core. For 8 workers - (per CPU socket), if not enough physical cores, both hyper-threads of 4 - physical cores can be used. As long as these conditions are met, the - actual lcore IDs are irrelevant. - -- --lpm: IPv4 routing table; - - Typically, there is a single rule for each TX port and the address spaces - of the rules do not overlap, e.g. for each TX_PORT used by the - application, the rule "10.0.TX_PORT.0/24 => TX_PORT" is included in the - list. -- --rsz: Ring sizes - - Typically, the default values are used (parameter not present in the - command line). -- --bsz: Burst sizes - - Typically, the default values are used (parameter not present in the - command line). -- --pos-lb: Position of the 1-byte header field within the input packet that is - used to determine the worker ID for each packet - - - Typically, the default value is used (parameter not present in the - command line). - -5. Traffic generator configuration - -The application is used to benchmark the penalty of packets going across -different CPU sockets. In the general case, the input packets are RX-ed by NIC -connected to CPU socket X, dispatched to worker running on CPU socket Y, TX-ed -by NIC connected to CPU socket Z. The typical cases under test are: AAA, AAB, -ABB, ABC (for 2-socket systems, ABC is actually ABA). - -The worker ID is determined by reading a 1-byte field from the input packet. Its -position is specified using the --pos-lb command line argument. For convenience, -the --pos-lb argument typically points to the last byte of the IPv4 source -address, e.g. the IPv4 source address for a traffic flow that shoud be processed -by WORKER_ID is: 0.0.0.WORKER_ID. - -The TX port is determined by the LPM rule that is hit by the IPv4 destination -address field read from each packet. Therefore, the traffic generator -configuration has to be in sync with the routing table of the application -(provided using the --lpm parameter). Given the convention described above of -LPM rules of: "10.0.TX_PORT.0/24 => TX_PORT", then packets with IPv4 destination -address of 10.0.TX_PORT.1 will be sent out by TX_PORT, regardless of the worker -lcore processing them. - -For a specific test case, the recommended flow configuration for each traffic -generator port (connected to a NIC attached to CPU socket X) is to create a -traffic flow for each pair of (worker on CPU socket Y, NIC TX port on CPU -socket Z) and equally divide the TX rate amongst all the traffic flows on the -same traffic generator port. This guarantees that all the workers on CPU -socket Y will be hit evenly and none of the NIC TX ports on CPU socket Z will be -oversubscribed. - -In this case, the same set of application command lines (testing different -packet I/O and worker set configurations) can be applied with no modifications -to test scenarios AAA, AAB, ABB, ABC/ABA by simply modifying two fields within -each of the traffic flows sent by the traffic generator on each of its ports. - -Test Case: Load Balancer -======================== - -Assuming that Logical core 4, 5, 6, 7 are connected to a traffic generator, -launch the ``load_balancer`` with the following arguments:: - - ./examples/load_balancer/build/load_balancer -l 3-7 -n 4 -- \ - --rx "(0,0,3),(1,0,3),(2,0,3),(3,0,3)" \ - --tx "(0,3),(1,3),(2,3),(3,3)" --w "4,5,6,7" \ - --lpm "1.0.0.0/24=>0;1.0.1.0/24=>1;1.0.2.0/24=>2;1.0.3.0/24=>3; " \ - --bsz "(10, 10), (10, 10), (10, 10)" --pos-lb 29 - -If the app run successfully, it will be the same as the shown in the terminal. :: - - ... - LPM rules: - 0: 1.0.0.0/24 => 0; - 1: 1.0.1.0/24 => 1; - 2: 1.0.2.0/24 => 2; - 3: 1.0.3.0/24 => 3; - Ring sizes: NIC RX = 1024; Worker in = 1024; Worker out = 1024; NIC TX = 1024; - Burst sizes: I/O RX (rd = 10, wr = 10); Worker (rd = 10, wr = 10); I/O TX (rd = 10, wr = 10) - Logical core 4 (worker 0) main loop. - Logical core 5 (worker 1) main loop. - Logical core 6 (worker 2) main loop. - Logical core 7 (worker 3) main loop. - Logical core 3 (I/O) main loop. diff --git a/tests/TestSuite_loadbalancer.py b/tests/TestSuite_loadbalancer.py deleted file mode 100644 index 84e534c..0000000 --- a/tests/TestSuite_loadbalancer.py +++ /dev/null @@ -1,154 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2020 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -""" -DPDK Test suite. - -Test Load Balancer. - -""" - -import dts -from packet import Packet -from test_case import TestCase -import utils -import time - - -class TestLoadbalancer(TestCase): - - def set_up_all(self): - """ - Run at the start of each test suite. - - Load Balancer prerequisites. - """ - # Verify that enough ports are available - global dutPorts - # Based on h/w type, choose how many ports to use - dutPorts = self.dut.get_ports(self.nic) - - # Verify that enough ports are available - self.verify(len(dutPorts) >= 4, "Insufficient ports for testing") - - cores = self.dut.get_core_list("all") - self.verify(len(cores) >= 5, "Insufficient cores for testing") - self.cores = self.dut.get_core_list("1S/5C/1T") - self.coremask = utils.create_mask(self.cores) - - global rx_port0, rx_port1, rx_port2, rx_port3, trafficFlow - rx_port0 = self.tester.get_local_port(dutPorts[0]) - rx_port1 = self.tester.get_local_port(dutPorts[1]) - rx_port2 = self.tester.get_local_port(dutPorts[2]) - rx_port3 = self.tester.get_local_port(dutPorts[3]) - - """ - Designation the traffic flow is the same as LPM rules, send and receive packet verification: - 0: 1.0.0.0/24 => 0; - 1: 1.0.1.0/24 => 1; - 2: 1.0.2.0/24 => 2; - 3: 1.0.3.0/24 => 3; - """ - trafficFlow = { - "Flow1": [rx_port0, "1.0.0.1"], - "Flow2": [rx_port1, "1.0.1.1"], - "Flow3": [rx_port2, "1.0.2.1"], - "Flow4": [rx_port3, "1.0.3.1"], - } - - out = self.dut.build_dpdk_apps("examples/load_balancer") - self.verify("Error" not in out, "compilation error 1") - self.verify("No such file" not in out, "compilation error 2") - - def set_up(self): - """ - Run before each test case. - """ - pass - - def test_load_balancer(self): - """ - --rx: Set the receive port, queue and main core; - --tx: Set the send port and main core; - --w: specify 4 workers lcores, - --lpm: IPv4 routing table, - --bsz: The number of packet is 10 for transceivers, - --pos-lb: Position of the 1-byte header field within the input packet that is used to - determine the worker ID for each packet - """ - - cmd = './examples/load_balancer/build/load_balancer -l {0}-{1} -n 4 -- --rx "(0,0,{2}),(1,0,{2}),(2,0,{2}),(3,0,{2})" '\ - '--tx "(0,{2}),(1,{2}),(2,{2}),(3,{2})" --w "{3},{4},{5},{6}" '\ - '--lpm "1.0.0.0/24=>0;1.0.1.0/24=>1;1.0.2.0/24=>2;1.0.3.0/24=>3;" '\ - '--bsz "(10, 10), (10, 10), (10, 10)" --pos-lb 29'.format(self.cores[0], self.cores[4], self.cores[0], self.cores[1], self.cores[2], self.cores[3], self.cores[4]) - - self.dut.send_expect(cmd, 'main loop.') - - # Verify the traffic flow according to Ipv4 route table - for flow in list(trafficFlow.keys()): - rx_port = trafficFlow[flow][0] - - for i in range(len(dutPorts)): - dstport = self.tester.get_local_port(dutPorts[i]) - pkt_count = 10 - inst = self.tester.tcpdump_sniff_packets(intf=self.tester.get_interface(rx_port), count=pkt_count) - - pkt = Packet(pkt_type='UDP', pkt_len=64) - dst_mac = self.dut.get_mac_address(dutPorts[i]) - pkt.config_layer('ether', {'dst': '%s' % dst_mac}) - pkt.config_layer('ipv4', {'src': "0.0.0.1", 'dst': '%s' % (trafficFlow[flow][1])}) - pkt.send_pkt(self.tester, tx_port=self.tester.get_interface(dstport), count=10) - # Wait for the sniffer to finish. - time.sleep(5) - - pkts = self.tester.load_tcpdump_sniff_packets(inst) - len_pkts = len(pkts) - - self.verify(len_pkts == pkt_count, "Packet number is wrong") - for i in range(len_pkts): - result = str(pkts[i].show) - self.verify("Ether" in result, "No packet received") - self.verify("src=0.0.0.1" + " dst=" + trafficFlow[flow][1] in result, "Wrong IP address") - self.verify("dst=%s" % dst_mac in result, "No packet received or packet missed") - - self.dut.send_expect("^C", "#") - - def tear_down(self): - """ - Run after each test case. - """ - self.dut.kill_all() - - def tear_down_all(self): - """ - Run after each test suite. - """ - pass -- 2.7.4