From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 4DFF2A05D3 for ; Wed, 22 May 2019 03:36:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06BD34C8B; Wed, 22 May 2019 03:36:15 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 6551814EC for ; Wed, 22 May 2019 03:36:13 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2019 18:36:11 -0700 X-ExtLoop1: 1 Received: from npg-dpdk-project-yinanwang-1.sh.intel.com ([10.67.110.176]) by fmsmga004.fm.intel.com with ESMTP; 21 May 2019 18:36:11 -0700 From: Yinan To: dts@dpdk.org Cc: Wang Yinan Date: Tue, 21 May 2019 18:33:50 +0000 Message-Id: <20190521183350.40370-1-yinan.wang@intel.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [dts] [PATCH v1] test_plans/virtio_user_for_container_networking: add test plan for container networking with virtio-user X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.15 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" From: Wang Yinan Signed-off-by: Wang Yinan --- ...ser_for_container_networking_test_plan.rst | 108 ++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 test_plans/virtio_user_for_container_networking_test_plan.rst diff --git a/test_plans/virtio_user_for_container_networking_test_plan.rst b/test_plans/virtio_user_for_container_networking_test_plan.rst new file mode 100644 index 0000000..2d68f5f --- /dev/null +++ b/test_plans/virtio_user_for_container_networking_test_plan.rst @@ -0,0 +1,108 @@ +.. Copyright (c) <2019>, 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. + +============================================== +Virtio_user for container networking test plan +============================================== + +Description +=========== + +Container becomes more and more popular for strengths, like low overhead, fast +boot-up time, and easy to deploy, etc. +Virtio, in essence, is a shm-based solution to transmit/receive packets. How is +memory shared? In VM's case, qemu always shares the whole physical layout of VM +to vhost backend. But it's not feasible for a container, as a process, to share +all virtual memory regions to backend. So only those virtual memory regions +(aka, hugepages initialized in DPDK) are sent to backend. It restricts that only +addresses in these areas can be used to transmit or receive packets. + +Limitations +----------- +We have below limitations in this solution: + * Cannot work with --huge-unlink option. As we need to reopen the hugepage + file to share with vhost backend. + * Cannot work with --no-huge option. Currently, DPDK uses anonymous mapping + under this option which cannot be reopened to share with vhost backend. + * Cannot work when there are more than VHOST_MEMORY_MAX_NREGIONS(8) hugepages. + If you have more regions (especially when 2MB hugepages are used), the option, + --single-file-segments, can help to reduce the number of shared files. + * Applications should not use file name like HUGEFILE_FMT ("%smap_%d"). That + will bring confusion when sharing hugepage files with backend by name. + * Root privilege is a must. DPDK resolves physical addresses of hugepages + which seems not necessary, and some discussions are going on to remove this + restriction. + +Test Case 1: packet forward test for container networking +========================================================= + +1. Mount hugepage:: + + mkdir /mnt/huge + mount -t hugetlbfs nodev /mnt/huge + +2. Bind one port to igb_uio, launch vhost:: + + ./testpmd -l 1-2 -n 4 --socket-mem 1024,1024  --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=1,client=0' -- -i + +2. Start a container instance with a virtio-user port:: + + docker run -i -t --privileged -v /root/dpdk/vhost-net:/tmp/vhost-net -v /mnt/huge:/dev/hugepages \ + -v /root/dpdk:/root/dpdk dpdk_image ./root/dpdk/x86_64-native-linuxapp-gcc/app/testpmd -l 3-4 -n 4 -m 1024 --no-pci --file-prefix=container \ + --vdev=virtio_user0,mac=00:11:22:33:44:10,path=/tmp/vhost-net -- -i + +3. Send packet with packet generator with different packet size,includes [64, 128, 256, 512, 1024, 1518], check virtio could receive and fwd packets correctly in container:: + + testpmd>show port stats all + +Test Case 2: packet forward with multi-queues for container networking +====================================================================== + +1. Mount hugepage:: + + mkdir /mnt/huge + mount -t hugetlbfs nodev /mnt/huge + +2. Bind one port to igb_uio, launch vhost:: + + ./testpmd -l 1-3 -n 4 --socket-mem 1024,1024  --file-prefix=vhost --vdev 'net_vhost0,iface=vhost-net,queues=2,client=0' -- -i --nb-cores=2 + +2. Start a container instance with a virtio-user port:: + + docker run -i -t --privileged -v /root/dpdk/vhost-net:/tmp/vhost-net -v /mnt/huge:/dev/hugepages \ + -v /root/dpdk:/root/dpdk dpdk_image ./root/dpdk/x86_64-native-linuxapp-gcc/app/testpmd -l 4-6 -n 4 -m 1024 --no-pci --file-prefix=container \ + --vdev=virtio_user0,mac=00:11:22:33:44:10,path=/tmp/vhost-net,queues=2 -- -i --rxq=2 --txq=2 --nb-cores=2 + +3. Send packet with packet generator with different packet size,includes [64, 128, 256, 512, 1024, 1518], check virtio could receive and fwd packets in container with two queues:: + + testpmd>show port stats all + testpmd>stop -- 2.17.1