test suite reviews and discussions
 help / color / mirror / Atom feed
From: "Tu, Lijuan" <lijuan.tu@intel.com>
To: "Peng, Yuan" <yuan.peng@intel.com>, "dts@dpdk.org" <dts@dpdk.org>
Cc: "Peng, Yuan" <yuan.peng@intel.com>
Subject: Re: [dts] [PATCH v2] test_plans: add qos_sched_test_plan.rst
Date: Thu, 31 Jan 2019 01:58:16 +0000	[thread overview]
Message-ID: <8CE3E05A3F976642AAB0F4675D0AD20E0BA1F222@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <1548393977-33133-1-git-send-email-yuan.peng@intel.com>

Applied, thanks

> -----Original Message-----
> From: dts [mailto:dts-bounces@dpdk.org] On Behalf Of Peng Yuan
> Sent: Friday, January 25, 2019 1:26 PM
> To: dts@dpdk.org
> Cc: Peng, Yuan <yuan.peng@intel.com>
> Subject: [dts] [PATCH v2] test_plans: add qos_sched_test_plan.rst
> 
> Add qos_sched_test_plan.rst to test_plans
> 
> Signed-off-by: Peng Yuan <yuan.peng@intel.com>
> 
> diff --git a/test_plans/qos_sched_test_plan.rst
> b/test_plans/qos_sched_test_plan.rst
> new file mode 100644
> index 0000000..ea781bd
> --- /dev/null
> +++ b/test_plans/qos_sched_test_plan.rst
> @@ -0,0 +1,126 @@
> +.. Copyright (c) <2011-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.
> +
> +======================
> +QoS Scheduler Tests
> +======================
> +
> +The QoS Scheduler results are produced using ''qos_sched'' application.
> +The application has a number of command line options::
> +
> +    ./qos_sched [EAL options] -- <APP PARAMS>
> +
> +Mandatory application parameters include:
> +-pfc “RX PORT, TX PORT, RX LCORE, WT LCORE, TX CORE”: Packet flow
> configuration.
> +Multiple pfc entities can be configured in the command line, having 4
> +or 5 items (if TX core defined or not).
> +
> +The profile configuration file "profile.cfg" defines all the
> +port/subport/pipe/traffic class/queue parameters needed for the QoS
> +scheduler configuration.
> +
> +The Port/Subport/Pipe/Traffic Class/Queue are the hierarchical entities
> +in a typical QoS application:
> +
> +1. A subport represents a predefined group of users.
> +
> +2. A pipe represents an individual user/subscriber.
> +
> +3. A traffic class is the representation of a different traffic type
> +   with a specific loss rate, delay and jitter requirements;
> +   such as data voice, video or data transfers.
> +
> +4. A queue hosts packets from one or multiple connections of the same type
> +   belonging to the same user.
> +
> +The detailed description of the application items and mode can be found
> +in https://doc.dpdk.org/guides/sample_app_ug/qos_scheduler.html
> +
> +Prerequisites
> +=============
> +The DUT must have four 10G Ethernet ports connected to four ports on
> +Tester that are controlled by the Scapy packet generator::
> +
> +    dut_port_0 <---> tester_port_0
> +    dut_port_1 <---> tester_port_1
> +    dut_port_2 <---> tester_port_2
> +    dut_port_3 <---> tester_port_3
> +
> +Or use IXIA as packet generator.
> +
> +Assume four DUT 10G Ethernet ports' pci device id is as the following::
> +
> +    dut_port_0 : "0000:05:00.0"
> +    dut_port_1 : "0000:05:00.1"
> +    dut_port_2 : "0000:05:00.2"
> +    dut_port_3 : "0000:05:00.3"
> +
> +1. Compile DPDK and sample with defining::
> +
> +    CONFIG_RTE_SCHED_COLLECT_STATS=y
> +
> +2. Bind four ports to dpdk igb_uio driver::
> +
> +    ./usertools/dpdk-devbind.py -b igb_uio 05:00.0 05:00.1 05:00:2
> + 05:00.3
> +
> +Test Case: single packet flow
> +=============================
> +1. This example uses a single packet flow configuration
> +   which creates one RX thread on lcore 5 reading from port 3
> +   and a worker thread on lcore 7 writing to port 2::
> +
> +    ./qos_sched -l 1,5,7 -n 4 -- --pfc "3,2,5,7" --cfg ../profile.cfg
> +
> +2. Set flows with different vlan ID, which represent different pipes.
> +   Each Rx flow is shaping to 1/4096 of Tx flow.
> +   Set flows with different Destination IP address (0.0.X.0),
> +   such as 100.0.1.0-100.0.4.0, which represent different tc.
> +   Check the Rx/Tx Bps too.
> +
> +Test Case: two packet flows
> +===========================
> +1. This example with two packet flow configurations using different ports
> +   but sharing the same core for QoS scheduler is given below::
> +
> +    ./qos_sched -l 1,2,6,7 -n 4 -- --pfc "3,2,2,6,7" --pfc "1,0,2,6,7"
> + --cfg ../profile.cfg
> +
> +2. Set flows to port 3 and port 1 with different vlan ID.
> +   Each Rx flow is shaping to 1/4096 of Tx flow.
> +   Set flows with different Destination IP address (0.0.X.0),
> +   such as 100.0.1.0-100.0.4.0, which represent different tc.
> +   Check the Rx/Tx Bps too.
> +
> +Note that independent cores for the packet flow configurations for each
> +of the RX, WT and TX thread are also supported, providing flexibility
> +to balance the work.
> +The EAL coremask/corelist is constrained to contain the default
> +mastercore 1 and the RX, WT and TX cores only.
> --
> 2.5.0


  reply	other threads:[~2019-01-31  1:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25  5:26 Peng Yuan
2019-01-31  1:58 ` Tu, Lijuan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-08-16  5:22 [dts] [PATCH v2]test_plans: " Peng Yuan
2019-08-28 10:45 ` Tu, Lijuan
2019-01-25  5:23 [dts] [PATCH v2] test_plans: " Wenjie Li

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=8CE3E05A3F976642AAB0F4675D0AD20E0BA1F222@SHSMSX101.ccr.corp.intel.com \
    --to=lijuan.tu@intel.com \
    --cc=dts@dpdk.org \
    --cc=yuan.peng@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).