From: "Liu, Yong" <yong.liu@intel.com>
To: "Xu, GangX" <gangx.xu@intel.com>, "dts@dpdk.org" <dts@dpdk.org>
Cc: "Xu, GangX" <gangx.xu@intel.com>
Subject: Re: [dts] [PTCH V1 1/2] add link status interrupt test plan
Date: Fri, 29 Apr 2016 18:02:11 +0000 [thread overview]
Message-ID: <86228AFD5BCD8E4EBFD2B90117B5E81E14F0B0C6@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <1461759504-30167-1-git-send-email-gangx.xu@intel.com>
Thanks, applied.
> -----Original Message-----
> From: dts [mailto:dts-bounces@dpdk.org] On Behalf Of xu,gang
> Sent: Wednesday, April 27, 2016 5:18 AM
> To: dts@dpdk.org
> Cc: Xu, GangX
> Subject: [dts] [PTCH V1 1/2] add link status interrupt test plan
>
> Signed-off-by: xu,gang <gangx.xu@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
> b/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
> would
> +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
> would
> +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
> a
> +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:
> disable/default/maximum)
> +
> +Prerequisites
> +=============
> +
> +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
> generator.
> +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
> be
> +changed. The lcore used to run the test application and the number of
> queues
> +per lcore could be changed.
> +
> +Test Case: Link Status Change
> +=============================
> +
> +Run the test application as above command. Then plug out the cable/fiber,
> or
> +simulate a disconnection. After several seconds, check if the link is
> actully
> +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.
> --
> 1.9.3
prev parent reply other threads:[~2016-04-29 18:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 12:18 xu,gang
2016-04-27 12:18 ` [dts] [PTCH V1 2/2] add link status interrupt test script xu,gang
2016-04-29 18:02 ` Liu, Yong [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=86228AFD5BCD8E4EBFD2B90117B5E81E14F0B0C6@SHSMSX103.ccr.corp.intel.com \
--to=yong.liu@intel.com \
--cc=dts@dpdk.org \
--cc=gangx.xu@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).