test suite reviews and discussions
 help / color / mirror / Atom feed
From: "Tu, Lijuan" <lijuan.tu@intel.com>
To: "Lin, Xueqin" <xueqin.lin@intel.com>, "dts@dpdk.org" <dts@dpdk.org>
Cc: "Lin, Xueqin" <xueqin.lin@intel.com>
Subject: Re: [dts] [PATCH v1] test_plans/kernelpf_iavf: add test plan for kernel	pf iavf
Date: Mon, 13 May 2019 07:28:48 +0000	[thread overview]
Message-ID: <8CE3E05A3F976642AAB0F4675D0AD20E0BA7FC7E@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <1556401026-77620-1-git-send-email-xueqin.lin@intel.com>

Applied, thanks

> -----Original Message-----
> From: dts [mailto:dts-bounces@dpdk.org] On Behalf Of Xueqin Lin
> Sent: Sunday, April 28, 2019 5:37 AM
> To: dts@dpdk.org
> Cc: Lin, Xueqin <xueqin.lin@intel.com>
> Subject: [dts] [PATCH v1] test_plans/kernelpf_iavf: add test plan for kernel pf
> iavf
> 
> Signed-off-by: Xueqin Lin <xueqin.lin@intel.com>
> 
> ---
>  test_plans/index.rst                   |   1 +
>  test_plans/kernelpf_iavf_test_plan.rst | 585
> +++++++++++++++++++++++++++++++++
>  2 files changed, 586 insertions(+)
>  create mode 100644 test_plans/kernelpf_iavf_test_plan.rst
> 
> diff --git a/test_plans/index.rst b/test_plans/index.rst index
> e6005da..f18e5f9 100644
> --- a/test_plans/index.rst
> +++ b/test_plans/index.rst
> @@ -138,6 +138,7 @@ The following are the test plans for the DPDK DTS
> automated test system.
>      vf_rss_test_plan
>      vf_to_vf_nic_bridge_test_plan
>      vf_vlan_test_plan
> +    kernelpf_iavf_test_plan
>      vhost_multi_queue_qemu_test_plan
>      vhost_pmd_xstats_test_plan
>      vhost_qemu_mtu_test_plan
> diff --git a/test_plans/kernelpf_iavf_test_plan.rst
> b/test_plans/kernelpf_iavf_test_plan.rst
> new file mode 100644
> index 0000000..0ca45e6
> --- /dev/null
> +++ b/test_plans/kernelpf_iavf_test_plan.rst
> @@ -0,0 +1,585 @@
> +.. Copyright (c) <2010-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.
> +
> +
> +==========================
> +Kernel PF + IAVF test plan
> +==========================
> +
> +Intel Adaptive Virtual Function(IAVF) is aimed to provide a common VF
> +for VM which means just need one unified VF driver so you don't have to
> +reload different VF driver when you upgrade the PF NIC.
> +One of the advantages is you don't have to do any modification for code
> +or hardware for an existing VM image running on the new NIC.
> +
> +Requirement
> +===========
> +This plan for IAVF only supports kernel PF scenario.
> +
> +Hardware
> +========
> +ICE driver NIC.
> +
> +Prerequisites
> +=============
> +Get the pci device id of DUT, for example::
> +
> +    ./usertools/dpdk-devbind.py -s
> +
> +    0000:18:00.0 'Device 1592' if=enp24s0f0 drv=ice unused=igb_uio
> +    0000:18:00.1 'Device 1592' if=enp24s0f1 drv=ice unused=igb_uio
> +
> +Create 1 VF from 1 kernel PF::
> +
> +    echo 1 > /sys/bus/pci/devices/0000\:18\:00.0/sriov_numvfs
> +
> +Set VF mac as 00:01:23:45:67:89::
> +
> +    ip link set $PF_INTF vf 0 mac 00:01:23:45:67:89
> +
> +Test IAVF cases on host or in qemu
> +
> +Bind VF device to igb_uio or vfio-pci
> +
> +Start up VF port::
> +
> +    ./testpmd -c f -n 4 -- -i
> +
> +Test case: VF basic RX/TX
> +=========================
> +Set rxonly forward, start testpmd
> +
> +Send 100 random packets from tester, check packets can be received
> +
> +Set txonly forward, start testpmd
> +
> +Check tester could receive the packets from application generated
> +
> +
> +Test case: VF MAC filter
> +========================
> +Disable promisc mode, add a new MAC to VF0 and then start testpmd::
> +
> +    testpmd> set promisc all off
> +    testpmd> mac_addr add 0 00:11:22:33:44:55
> +    testpmd> set fwd mac
> +    testpmd> start
> +
> +Use scapy to send 100 random packets with current VF0's MAC, verify the
> +packets can be received and forwarded by the VF
> +
> +Use scapy to send 100 random packets with new added VF0's MAC, verify
> +the packets can be received and forwarded by the VF::
> +
> +    p=Ether(dst="00:11:22:33:44:55")/IP()/Raw(load='X'*30)
> +
> +Use scapy to send 100 random packets with a wrong MAC to VF0, verify
> +the packets can't be received by the VF.
> +
> +Note::
> +    Not set VF MAC from kernel PF for this case, if set, will print
> +    "not permitted error" when add new MAC for VF.
> +
> +Test case: VF promisc
> +=====================
> +Enable kernel trust mode::
> +
> +    ip link set $PF_INTF vf 0 trust on
> +
> +Start VF testpmd, set mac forward and enable print output
> +
> +Use scapy to send random packets with current VF0's MAC, verify the
> +packets can be received and forwarded by the VF.
> +
> +Use scapy to send random packets with a wrong MAC to VF0, verify the
> +packets can be received and forwarded by the VF.
> +
> +Disable promisc mode::
> +
> +    testpmd> set promisc all off
> +
> +Use scapy to send random packets with current VF0's MAC, verify the
> +packets can be received and forwarded by the VF.
> +
> +Use scapy to send random packets with a wrong MAC to VF0, verify the
> +packets can't be received and forwarded by the VF.
> +
> +Enable promisc mode::
> +
> +    testpmd> set promisc all on
> +
> +Use scapy to send random packets with current VF0's MAC, verify the
> +packets can be received and forwarded by the VF.
> +
> +Use scapy to send random packets with a wrong MAC to VF0, verify the
> +packets can be received and forwarded by the VF.
> +
> +Disable kernel trust mode::
> +
> +    ip link set $PF_INTF vf 0 trust off
> +
> +Test case: VF multicast
> +=======================
> +Enable kernel trust mode::
> +
> +    ip link set $PF_INTF vf 0 trust on
> +
> +Start VF testpmd
> +
> +Disable promisc and multicast mode::
> +
> +    testpmd> set promisc all off
> +    testpmd> set allmulti all off
> +    testpmd> start
> +
> +Send packet with current VF0's MAC, and check VF can receive the packet.
> +
> +Send packet with multicast MAC 01:80:C2:00:00:08, and check VF can not
> +receive the packet.
> +
> +Enable multicast mode::
> +
> +    testpmd> set allmulti all on
> +
> +Send packet with current VF0's MAC, and check VF can receive the packet.
> +
> +Send packet with multicast MAC 01:80:C2:00:00:08, and check VF can
> +receive the packet.
> +
> +Disable kernel trust mode::
> +
> +    ip link set $PF_INTF vf 0 trust off
> +
> +Test case: VF broadcast
> +=======================
> +Disable VF promisc mode::
> +
> +    testpmd> set promisc all off
> +    testpmd> start
> +
> +Send packet with broadcast address ff:ff:ff:ff:ff:ff, and check VF can
> +receive the packet
> +
> +
> +Test case: add port based vlan on VF
> +====================================
> +Add pvid on VF0 from PF device::
> +
> +    ip link set $PF_INTF vf 0 vlan 2
> +
> +Send packet with same vlan id and check VF can receive
> +
> +Send packet with wrong vlan id and check VF can't receive
> +
> +Check PF device shows correct pvid setting::
> +
> +    ip link show $PF_INTF
> +    ...
> +    vf 0 MAC 00:01:23:45:67:89, vlan 2, spoof checking on, link-state
> + auto
> +
> +
> +Test case: remove port based vlan on VF
> +=======================================
> +Remove added vlan from PF device::
> +
> +    ip link set $PF_INTF vf 0 vlan 0
> +
> +Start testpmd and send packet without vlan and check VF can receive
> +
> +Set packet with vlan id 0 and check VF can receive
> +
> +Set packet with random id 1-4095 and check VF can't receive
> +
> +Check PF device doesn't show pvid setting::
> +
> +    ip link show $PF_INTF
> +
> +Test case: VF tagged vlan RX
> +============================
> +
> +Make sure port based vlan disabled on VF0
> +
> +Start testpmd with rxonly mode::
> +
> +     testpmd> set fwd rxonly
> +     testpmd> set verbose 1
> +     testpmd> start
> +
> +Send packet without vlan and check VF can receive
> +
> +Send packet with vlan 0 and check VF can receive
> +
> +Add vlan from VF driver::
> +
> +     testpmd> rx_vlan add 1 0
> +
> +Send packet with vlan 1 and check VF can receive
> +
> +Rerun above with random vlan and max vlan 4095, check VF can't receive
> +
> +Remove vlan on VF0::
> +
> +     testpmd> rx_vlan rm 1 0
> +
> +Send packet with vlan 0 and check VF can receive
> +
> +Send packet without vlan and check VF can receive
> +
> +Send packet with vlan 1 and check VF can't receive
> +
> +Test case: VF vlan insertion
> +============================
> +
> +Disable VF vlan strip::
> +
> +    testpmd> vlan set strip off 0
> +
> +Set vlan id 20 for tx_vlan::
> +
> +    testpmd> port stop all
> +    testpmd> tx_vlan set 0 20
> +    testpmd> port start all
> +    testpmd> set fwd mac
> +    testpmd> start
> +
> +Send normal packet::
> +
> +    p=Ether(dst="00:01:23:45:67:89")/IP()/Raw(load='X'*30)
> +
> +Verify packet that out from VF contains the vlan tag 20
> +
> +
> +Test case: VF vlan strip
> +========================
> +
> +Enable VF vlan strip::
> +
> +    testpmd> vlan set strip on 0
> +    testpmd> set fwd mac
> +    testpmd> start
> +
> +Send packets with vlan tag::
> +
> +
> + p=Ether(dst="00:01:23:45:67:89")/Dot1Q(id=0x8100,vlan=20)/IP()/Raw(loa
> + d='X'*30)
> +
> +Check that out from VF doesn't contain the vlan tag.
> +
> +Disable VF vlan strip::
> +
> +    testpmd> vlan set strip off 0
> +
> +Send packets with vlan tag::
> +
> +
> + Ether(dst="00:01:23:45:67:89")/Dot1Q(id=0x8100,vlan=20)/IP()/Raw(load=
> + 'X'*30)
> +
> +Check that out from VF contains the vlan tag.
> +
> +
> +Test case: VF without jumboframe
> +================================
> +
> +Ensure tester's port supports sending jumboframe::
> +
> +    ifconfig 'tester interface' mtu 9000
> +
> +Launch testpmd for VF port without enabling jumboframe option::
> +
> +    ./testpmd -c f -n 4 -- -i
> +
> +    testpmd> set fwd mac
> +    testpmd> start
> +
> +Check packet less than the standard maximum frame (1518) can be received.
> +
> +Check packet more than the standard maximum frame (1518) can not be
> received.
> +
> +Test case: VF with jumboframe
> +=============================
> +
> +Ensure tester's port supports sending jumboframe::
> +
> +    ifconfig 'tester interface' mtu 9000
> +
> +Launch testpmd for VF port with jumboframe option::
> +
> +    ./testpmd -c f -n 4 -- -i --max-pkt-len=3000
> +
> +    testpmd> set fwd mac
> +    testpmd> start
> +
> +Check that packet length larger than the standard maximum frame (1518)
> +and lower or equal to the maximum frame length can be received.
> +
> +Check that packet length larger than the configured maximum packet can
> +not be received.
> +
> +
> +Test case: VF RSS
> +=================
> +
> +Start command with multi-queues like below::
> +
> +   ./testpmd -c f -n 4 -- -i --txq=4 --rxq=4
> +
> +Config hash reta table::
> +
> +  testpmd> port config 0 rss reta (0,0)  testpmd> port config 0 rss
> + reta (1,1)  testpmd> port config 0 rss reta (2,2)  testpmd> port
> + config 0 rss reta (3,3)  ...
> +  testpmd> port config 0 rss reta (60,0)  testpmd> port config 0 rss
> + reta (61,1)  testpmd> port config 0 rss reta (62,2)  testpmd> port
> + config 0 rss reta (63,3)
> +
> +Enable IP/TCP/UDP RSS::
> +
> +  testpmd> port config all rss
> + (all|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none)
> +
> +Send different flow types' IP/TCP/UDP packets to VF port, check packets
> +are received by different configured queues.
> +
> +
> +Test case: VF HW checksum offload
> +=================================
> +
> +Enable HW checksum, set csum forward::
> +
> +    testpmd> port stop all
> +    testpmd> csum set ip hw 0
> +    testpmd> csum set udp hw 0
> +    testpmd> csum set tcp hw 0
> +    testpmd> csum set sctp hw 0
> +    testpmd> set fwd csum
> +    testpmd> set verbose 1
> +    testpmd> port start all
> +    testpmd> start
> +
> +Send packets with incorrect checksum to vf port, verify that the
> +packets can be received by VF port and checksum error reported, the
> +packets forwarded by VF port have the correct checksum value::
> +
> +    p=Ether()/IP(chksum=0x1234)/UDP()/Raw(load='X'*20)
> +    p=Ether()/IP()/TCP(chksum=0x1234)/Raw(load='X'*20)
> +    p=Ether()/IP()/UDP(chksum=0x1234)/Raw(load='X'*20)
> +
> +
> +Test case: VF SW checksum offload
> +=================================
> +
> +Enable SW checksum, set csum forward::
> +
> +    testpmd> port stop all
> +    testpmd> csum set ip sw 0
> +    testpmd> csum set udp sw 0
> +    testpmd> csum set tcp sw 0
> +    testpmd> csum set sctp sw 0
> +    testpmd> set fwd csum
> +    testpmd> set verbose 1
> +    testpmd> port start all
> +    testpmd> start
> +
> +Send packets with incorrect checksum to vf port, verify that the
> +packets can be received by VF port and checksum error reported, the
> +packets forwarded by VF port have the correct checksum value::
> +
> +    p=Ether()/IP(chksum=0x1234)/UDP()/Raw(load='X'*20)
> +    p=Ether()/IP()/TCP(chksum=0x1234)/Raw(load='X'*20)
> +    p=Ether()/IP()/UDP(chksum=0x1234)/Raw(load='X'*20)
> +
> +
> +Test case: VF TSO
> +=================
> +Turn off all hardware offloads on tester machine::
> +
> +   ethtool -K eth1 rx off tx off tso off gso off gro off lro off
> +
> +Change mtu for large packet::
> +
> +   ifconfig 'tester interface' mtu 9000
> +
> +Launch the ``testpmd`` with the following arguments, add "--max-pkt-len"
> +for large packet::
> +
> +   ./testpmd -c f -n 4 -- -i --port-topology=chained --max-pkt-len=9000
> +
> +Set csum forward::
> +
> +    testpmd> set fwd csum
> +    testpmd> set verbose 1
> +
> +Enable HW checksum::
> +
> +    testpmd> port stop all
> +    testpmd> csum set ip hw 0
> +    testpmd> csum set udp hw 0
> +    testpmd> csum set tcp hw 0
> +    testpmd> csum set sctp hw 0
> +
> +Set TSO turned on, set TSO size as 1460::
> +
> +    testpmd> tso set 1460 0
> +    testpmd> port start all
> +    testpmd> start
> +
> +Send few IP/TCP packets from tester machine to DUT. Check IP/TCP
> +checksum correctness in captured packet and verify correctness of HW
> +TSO offload for large packets. One large TCP packet (5214 bytes +
> +headers) segmented to four fragments (1460 bytes+header, 1460
> +bytes+header, 1460 bytes+header and 834 bytes + headers), checksums are
> also ok::
> +
> +
> +
> p=Ether()/IP(chksum=0x1234)/TCP(flags=0x10,chksum=0x1234)/Raw(RandStri
> + ng(5214))
> +
> +Transmitted packet::
> +
> +   21:48:24.214136 00:00:00:00:00:00 > 3c:fd:fe:9d:69:68, ethertype IPv6
> +   (0x86dd), length 5288: (hlim 64, next-header TCP (6) payload length: 5234)
> +    ::1.ftp-data > ::1.http: Flags [.], cksum 0xac95 (correct), seq 0:5214,
> +   ack 1, win 8192, length 5214: HTTP
> +
> +Captured packet::
> +
> +   21:48:24.214207 3c:fd:fe:9d:69:68 > 02:00:00:00:00:00, ethertype IPv6
> +   (0x86dd), length 1534: (hlim 64, next-header TCP (6) payload length: 1480)
> +   ::1.ftp-data > ::1.http: Flags [.], cksum 0xa641 (correct), seq 0:1460,
> +   ack 1, win 8192, length 1460: HTTP
> +   21:48:24.214212 3c:fd:fe:9d:69:68 > 02:00:00:00:00:00, ethertype IPv6
> +   (0x86dd), length 1534: (hlim 64, next-header TCP (6) payload length: 1480)
> +   ::1.ftp-data > ::1.http: Flags [.], cksum 0xae89 (correct), seq 1460:2920,
> +   ack 1, win 8192, length 1460: HTTP
> +   21:48:24.214213 3c:fd:fe:9d:69:68 > 02:00:00:00:00:00, ethertype IPv6
> +   (0x86dd), length 1534: (hlim 64, next-header TCP (6) payload length: 1480)
> +   ::1.ftp-data > ::1.http: Flags [.], cksum 0xfdb6 (correct), seq 2920:4380,
> +   ack 1, win 8192, length 1460: HTTP
> +   21:48:24.214215 3c:fd:fe:9d:69:68 > 02:00:00:00:00:00, ethertype IPv6
> +   (0x86dd), length 908: (hlim 64, next-header TCP (6) payload length: 854)
> +   ::1.ftp-data > ::1.http: Flags [.], cksum 0xe629 (correct), seq 4380:5214,
> +   ack 1, win 8192, length 834: HTTP
> +
> +Set TSO turned off::
> +
> +    testpmd> tso set 0 0
> +
> +Send few IP/TCP packets from tester machine to DUT. Check IP/TCP
> +checksum correctness in captured packet and verify correctness of HW
> +TSO offload for large packets, but don't do packet segmentation.
> +
> +Test case: VF port stop/start
> +=============================
> +
> +Stop VF port::
> +
> +    testpmd> port stop all
> +
> +Start VF port::
> +
> +    testpmd> port start all
> +
> +Repeat above stop and start port for 10 times
> +
> +Send packets from tester
> +
> +Check VF could receive packets
> +
> +
> +Test case: VF statistics reset
> +==============================
> +
> +Check VF port stats::
> +
> +    testpmd> show port stats all
> +
> +Clear VF port stats::
> +
> +    testpmd> clear port stats all
> +
> +Check VF port stats, RX-packets and TX-packets are 0
> +
> +Set mac forward, enable print out
> +
> +Send 100 packets from tester
> +
> +Check VF port stats, RX-packets and TX-packets are 100
> +
> +Clear VF port stats
> +
> +Check VF port stats, RX-packets and TX-packets are 0
> +
> +Test case: VF information
> +=========================
> +
> +Start testpmd
> +
> +Show VF port information, check link, speed...information correctness::
> +
> +    testpmd> show port info all
> +
> +Set mac forward, enable print out
> +
> +Send 100 packets from tester
> +
> +Check VF port stats, RX-packets and TX-packets are 100
> +
> +
> +Test case: VF RX interrupt
> +==========================
> +Build l3fwd-power
> +
> +Create one VF from kernel PF0, create on VF from kernel PF1::
> +
> +    echo 1 > /sys/bus/pci/devices/0000\:18\:00.0/sriov_numvfs
> +    echo 1 > /sys/bus/pci/devices/0000\:18\:00.1/sriov_numvfs
> +
> +Bind VFs to vfio-pci::
> +
> +    ./usertools/dpdk-devbind.py -b vfio-pci 18:01.0 18:11.0
> +
> +Start l3fwd power with one queue per port::
> +
> +    ./examples/l3fwd-power/build/l3fwd-power -l 6,7 -n 4 -- \
> +    -p 0x3 --config '(0,0,6),(1,0,7)'
> +
> +Send one packet to VF0 and VF1, check that thread on core6 and core7
> waked up::
> +
> +    L3FWD_POWER: lcore 6 is waked up from rx interrupt on port 0 queue 0
> +    L3FWD_POWER: lcore 7 is waked up from rx interrupt on port 0 queue
> + 0
> +
> +Check the packet has been normally forwarded.
> +
> +After the packet forwarded, thread on core6 and core 7 will return to sleep::
> +
> +    L3FWD_POWER: lcore 6 sleeps until interrupt triggers
> +    L3FWD_POWER: lcore 7 sleeps until interrupt triggers
> +
> +Send packet flows to VF0 and VF1, check that thread on core6 and core7
> +will keep up awake.
> --
> 2.5.5


      reply	other threads:[~2019-05-13  7:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-27 21:37 Xueqin Lin
2019-05-13  7:28 ` Tu, Lijuan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8CE3E05A3F976642AAB0F4675D0AD20E0BA7FC7E@SHSMSX101.ccr.corp.intel.com \
    --to=lijuan.tu@intel.com \
    --cc=dts@dpdk.org \
    --cc=xueqin.lin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).