[dpdk-dev] [PATCH 0/5] Support virtio multicast feature
Tested-by: Xiaonan Zhang This patch includes five files, and has been tested by Intel. Please see information as the following: Host: Fedora 20 x86_64, Linux Kernel 3.11.10-301.fc20.x86_64, GCC 4.8.3 20140624 Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576 Guest: Fedora 20 x86_64, Linux Kernel 3.11.10-301.fc20.x86_64, GCC 4.8.3 20140624 Qemu emulator 1.4.2 This patch tests with user space vhost driver library patch. We verified zero copy and one copy test cases for functional and performance using multicast address. Total case Passed Failed 10 10 0 -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ouyang Changchun Sent: Monday, August 25, 2014 10:09 AM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH 0/5] Support virtio multicast feature This patch series support multicast feature in virtio and vhost. The vhost backend enables the promiscuous mode and config ETH_VMDQ_ACCEPT_BROADCAST and ETH_VMDQ_ACCEPT_MULTICAST in VMDQ offload register to receive the multicast and broadcast packets. The virtio frontend provides the functionality of enabling and disabling the multicast and promiscuous mode. Changchun Ouyang (2): Set VM offload register according to VMDQ config for IGB PMD to support broadcast and multicast packets. Add new API in virtio for supporting promiscuous and allmulticast enable and disable. Ouyang Changchun (3): Add RX mode in VMDQ config and set the register PFVML2FLT for IXGBE PMD; this makes VMDQ accept broadcast and multicast packets. To let US-vHOST accept and forward broadcast and multicast packets: Add promiscurous option into command line; set VMDQ RX mode into: ETH_VMDQ_ACCEPT_BROADCAST|ETH_VMDQ_ACCEPT_MULTICAST. Specify rx_mode as 0 for 2 other samples: vmdq and vhost-xen. examples/vhost/main.c | 27 -- examples/vhost_xen/main.c | 1 + examples/vmdq/main.c | 1 + lib/librte_ether/rte_ethdev.h | 1 + lib/librte_pmd_e1000/igb_rxtx.c | 20 +++ lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 16 ++ lib/librte_pmd_virtio/virtio_ethdev.c | 98 ++- 7 files changed, 159 insertions(+), 5 deletions(-) -- 1.8.4.2
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
Tested-by: Xiaonan zhang - OS: Fedora21 3.19.1-201.fc21.x86_64 - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC) - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 01) - Default x86_64-native-linuxapp-gcc configuration - Total 1 cases, 1 passed, 0 failed - Test case: Used Qos example to verified - Traffic shaping for subport. Check that the subport rate is enforced. Set the subport output rate to x% of line rate (x = 10 .. 100). Set the subport TC limits high (100% line rate each), so they do not constitute limitations. Input traffic is 100% line rate. Different tb period and tb credits, therefore different output rate, are tried: 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport is Tb credits per period / Tb period.) The traffic is injected change subport value random. Other parameters are same before tests and they don't change here. Cmdline: ./examples/qos_sched/build/qos_sched -c 0xe -n 4 -- --pfc "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg" The result is this table: +---+--+ | Subport output rate | Subport output rate | | (% line rate) | (Mpps) | +---+---+--+---+ | Expected | Actual| Expected | Actual| +---+---+--+---+ Signed-off-by: Xiaonan Zhang -Original Message- From: Zhang, Helin Sent: Wednesday, April 01, 2015 10:50 AM To: Liang, Cunming; dev at dpdk.org Cc: Zhang, XiaonanX; Dumitrescu, Cristian Subject: RE: [PATCH] i40e: fix no effect wait_to_complete on link_get > -Original Message- > From: Liang, Cunming > Sent: Wednesday, April 1, 2015 10:34 AM > To: dev at dpdk.org > Cc: Zhang, Helin; Zhang, XiaonanX; Dumitrescu, Cristian; Liang, Cunming > Subject: [PATCH] i40e: fix no effect wait_to_complete on link_get > > API *rte_eth_link_get* expect to call a wait to complete link_update. > That's the difference between *rte_eth_link_get_nowait*. > The patch fixes the issue that i40e link_update ignores the wait_to_complete > flag. > The issue impacts those applications calling rte_eth_link_get to get wrong > intermediate link status. > > Signed-off-by: Cunming Liang Acked-by: Helin Zhang > --- > lib/librte_pmd_i40e/i40e_ethdev.c | 29 +++-- > 1 file changed, 19 insertions(+), 10 deletions(-)
[dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
Hi Thomas, First and foremost, We found this problem with using Qos example on Fedora21 platform, there are our reproduce test steps as follows. We used this example found FVL 4*10G NIC link status caused to our Qos example could not boot normally in our dpdk2.0 Release Cycle; In addition, it is performance case about our FVL 4 * 10G NIC, as you know, our performance result currently should not be public; And also that's why our expectation performance data are empty. In a nutshell, We have verified this patch and confirmed the Qos example could run and get performance data after we applied this patch to our code. Thanks. Best Regards, Xiaonan -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Thursday, April 02, 2015 3:52 AM To: Zhang, XiaonanX; Cao, Waterman Cc: dev at dpdk.org; Zhang, Helin; Liang, Cunming Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get Hi, 2015-04-01 06:10, Zhang, XiaonanX: > > Tested-by: Xiaonan zhang > > - OS: Fedora21 3.19.1-201.fc21.x86_64 > - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC) > - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz > - NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 > for 10GbE SFP+ [8086:1572] (rev 01) > - Default x86_64-native-linuxapp-gcc configuration > - Total 1 cases, 1 passed, 0 failed > > - Test case: Used Qos example to verified > - What is the relation between link status timeout and qos_sched? > Traffic shaping for subport. Check that the subport rate is enforced. > > Set the subport output rate to x% of line rate (x = 10 .. 100). Set the > subport TC limits high (100% line rate each), so they do not constitute > limitations. Input traffic is 100% line rate. > > Different tb period and tb credits, therefore different output rate, are > tried: 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport > is Tb credits per period / Tb period.) > The traffic is injected change subport value random. > > Other parameters are same before tests and they don't change here. > > Cmdline: ./examples/qos_sched/build/qos_sched -c 0xe -n 4 -- --pfc > "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg" > > The result is this table: > > > +---+--+ > | Subport output rate | Subport output rate | > | (% line rate) | (Mpps) | > +---+---+--+---+ > | Expected | Actual| Expected | Actual| > +---+---+--+---+ This table is empty. > > Signed-off-by: Xiaonan Zhang It seems that this test report is not relevant. It will be ignored in the commit message. Sorry
[dpdk-dev] [PATCH] vmxnet3: set txq_flags in default TX conf
Tested-by: Xiaonan Zhang - Tested Commit: Pablo - OS: Fedora20 3.15.8-200.fc20.x86_64 - GCC: gcc version 4.8.3 20140624 - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] - Default x86_64-native-linuxapp-gcc configuration - Total 6 cases, 6 passed, 0 failed - Test Environment setup - Topology #1: Create 2VMs (Fedora 20, 64bit);for each VM, pass through one physical port(Niantic 82599) to VM, and also create one virtual device: vmxnet3 in VM. Between two VMs, use one vswitch to connect 2 vmxnet3. In summary, PF1 and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2.The traffic flow for l2fwd/l3fwd is as below: Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> Ixia. - Topology #2: Create 1VM (Fedora 20, 64bit), on this VM, created 2 vmxnet3, called vmxnet3A, vmxnet3B; create 2 vswitch, vswitchA connecting PF1 and vmxnet3A, while vswitchB connecting PF2 and vmxnet3B. The traffic flow is as below: Ixia -> PF1 -> vswitchA -> vmxnet3A -> vmxnet3B -> vswitchB -> PF2 -> Ixia. - Test Case1: L2fwd with Topology#1 Description: Set up topology#1(in prerequisite session), and bind PF1, PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l2fwd example in 2VMs: ./build/l2fwd -c f -n 4 -- -p 0x3 - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the flow should have PF1's MAC as destination MAC. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case2: L3fwd-VF with Topology#1 Description: Set up topology#1(in prerequisite session), and bind PF1, PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio) Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l3fwd-vf example in 2VMs: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 --config "(0,0,1),(1,0,2)" - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the flow should have PF1's MAC as destination MAC and have 2.1.1.x as destination IP. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case3: L2fwd with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l2fwd example in VM1: ./build/l2fwd -c f -n 4 -- -p 0x3 - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to port0 (vmxnet3A), and the flow should have port0's MAC as destination MAC. Check if ixia port2 have received the 5 packets. Similar things need to be done at ixia port2. Expected test result: Passed - Test Case4: L3fwd-VF with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l3fwd-vf example in VM1: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 --config "(0,0,1),(1,0,2)" - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to port0(vmxnet3A), and the flow should have port0's MAC as destination MAC and have 2.1.1.x as destination IP. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case5: Timer test with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Command / instruction: Build timer sample and run the sample
[dpdk-dev] vmxnet3 and Linux FC20 OS platform, example directory could not compiled success
Hi Pablo and Thomas, We use latest package DPDK-1.8-rc5, and we found some compiled errors, Our Test Environment setup as follows: - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] - Default x86_64-native-linuxapp-gcc configuration main.o: In function `signal_handler': main.c:(.text+0x7): undefined reference to `rte_eth_dev_count' main.c:(.text+0x1a): undefined reference to `rte_exit' main.c:(.text+0x4a): undefined reference to `rte_eth_dev_close' main.o: In function `rte_pktmbuf_free': main.c:(.text+0x9c): undefined reference to `per_lcore__lcore_id' main.c:(.text+0x2df): undefined reference to `rte_eal_has_hugepages' main.c:(.text+0x354): undefined reference to `per_lcore__lcore_id' main.c:(.text+0x6fa): undefined reference to `rte_mem_virt2phy' main.o: In function `send_burst': main.c:(.text+0x797): undefined reference to `rte_eth_devices' main.c:(.text+0x79d): undefined reference to `rte_eth_devices' main.o: In function `main_loop': main.c:(.text+0x819): undefined reference to `rte_get_tsc_hz' main.c:(.text+0x820): undefined reference to `per_lcore__lcore_id' main.c:(.text+0x870): undefined reference to `rte_logs' main.c:(.text+0x879): undefined reference to `rte_logs' main.c:(.text+0x893): undefined reference to `rte_log' main.c:(.text+0x8aa): undefined reference to `rte_logs' main.c:(.text+0x8b3): undefined reference to `rte_logs' main.c:(.text+0x8cf): undefined reference to `rte_log' main.c:(.text+0x8e7): undefined reference to `rte_logs' main.c:(.text+0x8fa): undefined reference to `rte_logs' main.c:(.text+0x916): undefined reference to `rte_log' main.c:(.text+0x952): undefined reference to `rte_cycles_vmware_tsc_map' main.c:(.text+0x9c3): undefined reference to `rte_eth_devices' main.c:(.text+0x9d6): undefined reference to `rte_eth_devices' main.c:(.text+0xe33): undefined reference to `rte_eth_devices' main.o: In function `main': main.c:(.text.startup+0x34): undefined reference to `rte_eal_init' main.c:(.text.startup+0x10d): undefined reference to `rte_exit' main.c:(.text.startup+0x1f9): undefined reference to `rte_strsplit' main.c:(.text.startup+0x33c): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0x360): undefined reference to `lcore_config' main.c:(.text.startup+0x443): undefined reference to `rte_eth_dev_count' main.c:(.text.startup+0x4cb): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0x5dd): undefined reference to `rte_eth_dev_configure' main.c:(.text.startup+0x600): undefined reference to `rte_eth_macaddr_get' main.c:(.text.startup+0x633): undefined reference to `lcore_config' main.c:(.text.startup+0x6fb): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0x754): undefined reference to `rte_pktmbuf_pool_init' main.c:(.text.startup+0x786): undefined reference to `rte_pktmbuf_init' main.c:(.text.startup+0x78b): undefined reference to `rte_mempool_create' main.c:(.text.startup+0x7de): undefined reference to `rte_lpm_create' main.c:(.text.startup+0x843): undefined reference to `rte_lpm_add' main.c:(.text.startup+0x89c): undefined reference to `rte_exit' main.c:(.text.startup+0x8a1): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0x8be): undefined reference to `lcore_config' main.c:(.text.startup+0x8e3): undefined reference to `rte_eth_dev_info_get' main.c:(.text.startup+0x90e): undefined reference to `rte_eth_tx_queue_setup' main.c:(.text.startup+0x931): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0x95a): undefined reference to `lcore_config' main.c:(.text.startup+0x981): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0xa17): undefined reference to `rte_eth_rx_queue_setup' main.c:(.text.startup+0xaaf): undefined reference to `rte_eth_dev_start' main.c:(.text.startup+0xae3): undefined reference to `rte_eal_mp_remote_launch' main.c:(.text.startup+0xaea): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0xaf8): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0xb14): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0xb22): undefined reference to `rte_eal_get_configuration' main.c:(.text.startup+0xb35): undefined reference to `rte_eal_wait_lcore' main.c:(.text.startup+0xb77): undefined reference to `rte_exit' main.c:(.text.startup+0xbb9): undefined reference to `rte_exit' main.c:(.text.startup+0xbd5): undefined reference to `rte_exit' main.c:(.text.startup+0xbef): undefined reference to `rte_exit' main.c:(.text.startup+0xc04): undefined reference to `rte_exit' main.o:main.c:(.text.startup+0xc44): more undefined references to `rte_exit' follow collect2: error: ld returned 1 exit status make[1]: *** [l3fwd-vf] Error 1 make: *** [all] Error 2 Best Regards Xiaonan -
[dpdk-dev] [PATCH 1/2] 10G PMD: vectorized RX and TX functions
This patch set contains the vectorized PMD implementation for the Intel DPDK.
This code was previously released under a proprietary license, but is now
being released under a BSD license to allow its integration with the rest
of the Intel DPDK codebase.
Bruce Richardson (2):
10G PMD: New vectorized functions for RX/TX
10G PMD: enable vector PMD compile for 64b linux
config/defconfig_x86_64-default-linuxapp-gcc |2 +
config/defconfig_x86_64-default-linuxapp-icc |2 +
lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c| 726 ++
3 files changed, 730 insertions(+), 0 deletions(-)
create mode 100644 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
Test-by: XiaonanX Zhang xiaonanx.zhang at intel.com
Compile pass
>>Compile OS: FC20 x86_64
>>Kernel version: 3.13.6-200
>>GCC version: 4.8.2
>>Server: Crownpass
New file containing optimized receive and transmit functions which
use 128bit vector instructions to improve performance. When conditions
permit, these functions will be enabled at runtime by the device
initialization routines already in the PMD.
Signed-off-by: Bruce Richardson http://dpdk.org/ml/listinfo/dev>>
---
lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 726 +
1 files changed, 726 insertions(+), 0 deletions(-)
create mode 100644 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
new file mode 100644
index 000..1cfdbe9
--- /dev/null
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
@@ -0,0 +1,726 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 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.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ixgbe_logs.h"
+#include "ixgbe/ixgbe_api.h"
+#include "ixgbe/ixgbe_vf.h"
+#include "ixgbe_ethdev.h"
+#include "ixgbe/ixgbe_dcb.h"
+
+#include "ixgbe_rxtx.h"
+
+#include
+#include
+#include
+
+#ifndef __INTEL_COMPILER
+#pragma GCC diagnostic ignored "-Wcast-qual"
+#endif
+
+static struct rte_mbuf mb_def = {
+
+ .ol_flags = 0,
+ {
+ .pkt = {
+ .data_len = 0,
+ .pkt_len = 0,
+
+ .vlan_macip = {
+ .data = 0,
+ },
+ .hash = {
+ .rss = 0,
+ },
+
+ .nb_segs = 1,
+ .in_port = 0,
+
+ .next = NULL,
+ .data = NULL,
+ },
+ },
+};
+
+static inline void
+ixgbe_rxq_rearm (struct igb_rx_queue * rxq)
+{
+ int i;
+ uint16_t rx_id;
+ volatile union ixgbe_adv_rx_desc *rxdp;
+ struct igb_rx_entry *rxep = &rxq->sw_ring[rxq->rxrearm_start];
+ struct rte_mbuf *mb0, *mb1;
+
[dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
Tested-by: Xiaonan Zhang - Tested Commit: Yong Wang - OS: Fedora20 3.15.8-200.fc20.x86_64 - GCC: gcc version 4.8.3 20140624 - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] - Default x86_64-native-linuxapp-gcc configuration - Total 6 cases, 6 passed, 0 failed - Test Environment setup - Topology #1: Create 2VMs (Fedora 20, 64bit);for each VM, pass through one physical port(Niantic 82599) to VM, and also create one virtual device: vmxnet3 in VM. Between two VMs, use one vswitch to connect 2 vmxnet3. In summary, PF1 and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2.The traffic flow for l2fwd/l3fwd is as below: Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> Ixia. - Topology #2: Create 1VM (Fedora 20, 64bit), on this VM, created 2 vmxnet3, called vmxnet3A, vmxnet3B; create 2 vswitch, vswitchA connecting PF1 and vmxnet3A, while vswitchB connecting PF2 and vmxnet3B. The traffic flow is as below: Ixia -> PF1 -> vswitchA -> vmxnet3A -> vmxnet3B -> vswitchB -> PF2 -> Ixia. - Test Case1: L2fwd with Topology#1 Description: Set up topology#1(in prerequisite session), and bind PF1, PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l2fwd example in 2VMs: ./build/l2fwd -c f -n 4 -- -p 0x3 - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the flow should have PF1's MAC as destination MAC. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case2: L3fwd-VF with Topology#1 Description: Set up topology#1(in prerequisite session), and bind PF1, PF2, Vmxnet3A, vmxnet3B to DPDK poll-mode driver (igb_uio) Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l3fwd-vf example in 2VMs: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 --config "(0,0,1),(1,0,2)" - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to PF1, and the flow should have PF1's MAC as destination MAC and have 2.1.1.x as destination IP. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case3: L2fwd with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l2fwd example in VM1: ./build/l2fwd -c f -n 4 -- -p 0x3 - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to port0 (vmxnet3A), and the flow should have port0's MAC as destination MAC. Check if ixia port2 have received the 5 packets. Similar things need to be done at ixia port2. Expected test result: Passed - Test Case4: L3fwd-VF with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Increase the flow at line rate (uni-directional traffic), send the flow at different packet size (64bytes, 128bytes, 256bytes, 512bytes, 1024bytes, 1280bytes and 1518bytes) and check the received packets/rate to see if any unexpected behavior, such as no receives after N packets. Command / instruction: To run the l3fwd-vf example in VM1: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 --config "(0,0,1),(1,0,2)" - Test IXIA Flow prerequisite: Ixia port1 sends 5 packets to port0(vmxnet3A), and the flow should have port0's MAC as destination MAC and have 2.1.1.x as destination IP. Check if ixia port2 have received the 5 packets. Expected test result: Passed - Test Case5: Timer test with Topology#2 Description: Set up topology#2(in prerequisite session), and bind vmxnet3A and vmxnet3B to DPDK poll-mode driver (igb_uio). Command / instruction: Build timer sample and run the sa
