[dts] [PTCH V1 1/2] add link status interrupt test plan
yong.liu at intel.com
Fri Apr 29 20:02:11 CEST 2016
> -----Original Message-----
> From: dts [mailto:dts-bounces at dpdk.org] On Behalf Of xu,gang
> Sent: Wednesday, April 27, 2016 5:18 AM
> To: dts at dpdk.org
> Cc: Xu, GangX
> Subject: [dts] [PTCH V1 1/2] add link status interrupt test plan
> Signed-off-by: xu,gang <gangx.xu at intel.com>
> test_plans/link_status_interrupt_test_plan.rst | 65
> 1 file changed, 65 insertions(+)
> create mode 100644 test_plans/link_status_interrupt_test_plan.rst
> diff --git a/test_plans/link_status_interrupt_test_plan.rst
> new file mode 100644
> index 0000000..60d9716
> --- /dev/null
> +++ b/test_plans/link_status_interrupt_test_plan.rst
> @@ -0,0 +1,65 @@
> +.. <COPYRIGHT_TAG>
> +Link Status Detect
> +This tests for Detect Link Status feature can be run on linux userspace.
> +It is to check if the userspace interrupt can be received after plugging
> +in/out the cable/fiber on specified NIC port, and if the link status can
> +be updated correctly. Futhermore, it would be better to check if packets
> +can be received and sent on a specified port after its link has just up.
> +So it may need layer 2 forwarding at the same time.
> +For layer 2 forwarding, a packet received on a RX port (RX_PORT), it
> +be transmitted from a TX port (TX_PORT=RX_PORT+1) if RX_PORT is even;
> +otherwise from a TX port (TX_PORT=RX_PORT-1) if RX_PORT is odd. Before
> +being transmitted, the source mac address of the packet would be replaced
> +by the mac address of the TX port, while the destination mac address
> +be replaced by 00:09:c0:00:00:TX_PORT_ID. The test application should be
> +run with the wanted paired ports configured using the coremask parameter
> +via the command line. i.e. port 0 and 1 is a valid pair, while port 1 and
> +2 isn't. The test is performed by running the test application and using
> +traffic generator.
> +The ``link_status_interrupt`` application is run with EAL parameters and
> +parameters for the application itself. This application supports three
> +parameters for itself.
> + - ``-p PORTMASK``: hexadecimal bitmask of ports to config
> + - ``-q NQ``: number of queue per lcore (default is 1)
> + - ``-T PERIOD``: refresh periond in seconds (0/10/86400:
> +Support igb_uio and vfio driver, if used vfio, kernel need 3.6+ and
> enable vt-d in bios.
> +When used vfio , used "modprobe vfio" and "modprobe vfio-pci" insmod
> vfiod driver, then used
> +"./tools/dpdk_nic_bind.py --bind=vfio-pci device_bus_id" to bind vfio
> driver to test driver.
> +The test app need add a cmdline, "--vfio-intr=int_x"
> +Assume port 0 and 1 are connected to the remote ports, e.g. packet
> +To run the test application in linuxapp environment with 4 lcores, 2
> ports and
> +2 RX queues per lcore::
> + $ ./link_status_interrupt -c f -- -q 2 -p 0x3
> +Also, if the ports need to be tested are different, the port mask should
> +changed. The lcore used to run the test application and the number of
> +per lcore could be changed.
> +Test Case: Link Status Change
> +Run the test application as above command. Then plug out the cable/fiber,
> +simulate a disconnection. After several seconds, check if the link is
> +off. Then plug in the cable/fiber, or simulate a connection. After
> several seconds,
> +check if the link is actually up, and print its information about duplex
> and speed.
> +Test Case: Port available
> +Run the test application as above command with cable/fiber plugged out
> from both
> +port 0 and 1, then plug it in. After several seconds and the link of all
> the ports
> +is up. Together with packet generator, do layer 2 forwarding, and check
> if the
> +packets can be received on port 0/1 and sent out on port 1/0.
More information about the dts