From: Stephen Hemminger <stephen@networkplumber.org>
To: "Liang, Cunming" <cunming.liang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on link_get
Date: Thu, 2 Apr 2015 15:18:32 -0700 [thread overview]
Message-ID: <CAOaVG17Let-pZyWuqBipa97jZh-V7h7i5CLPF+4DrM3ShoDVEA@mail.gmail.com> (raw)
In-Reply-To: <D0158A423229094DA7ABF71CF2FA0DA311924222@shsmsx102.ccr.corp.intel.com>
The qos_scheduler has a 32 bit speed value and therefore I doubt it will
work work at 40G
On Wed, Apr 1, 2015 at 6:44 PM, Liang, Cunming <cunming.liang@intel.com>
wrote:
> Hi Thomas,
>
> > What is the relation between link status timeout and qos_sched?
> [LCM] Validation team found qos_sched test failure on i40e. The sample
> depends on link speed to calc the percentage.
> The root cause comes from that i40e link_get hasn't support
> wait_to_complete well.
> I agree with you it should add more description in test report why 'Used
> QoS example to verified'.
>
> > > +-----------------------+----------------------+
> > > | Subport output rate | Subport output rate |
> > > | (% line rate) | (Mpps) |
> > > +-----------+-----------+----------+-----------+
> > > | Expected | Actual | Expected | Actual |
> > > +-----------+-----------+----------+-----------+
> >
> > This table is empty.
> [LCM] It's useless, should be omitted I think.
>
> Cunming
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Thursday, April 02, 2015 3:52 AM
> > To: Zhang, XiaonanX; Cao, Waterman
> > Cc: dev@dpdk.org; Zhang, Helin; Liang, Cunming
> > Subject: Re: [dpdk-dev] [PATCH] i40e: fix no effect wait_to_complete on
> link_get
> >
> > Hi,
> >
> > 2015-04-01 06:10, Zhang, XiaonanX:
> > >
> > > Tested-by: Xiaonan zhang<xiaonanx.zhang@intel.com>
> > >
> > > - OS: Fedora21 3.19.1-201.fc21.x86_64
> > > - GCC: gcc version 4.9.1 20140930 (Red Hat 4.9.1-11) (GCC)
> > > - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> > > - NIC: Ethernet controller [0200]: Intel Corporation Ethernet
> Controller X710 for
> > 10GbE SFP+ [8086:1572] (rev 01)
> > > - Default x86_64-native-linuxapp-gcc configuration
> > > - Total 1 cases, 1 passed, 0 failed
> > >
> > > - Test case: Used Qos example to verified
> > > -------------------------------------
> >
> > What is the relation between link status timeout and qos_sched?
> >
> > > Traffic shaping for subport. Check that the subport rate is enforced.
> > >
> > > Set the subport output rate to x% of line rate (x = 10 .. 100). Set
> the subport TC
> > limits high (100% line rate each), so they do not constitute
> limitations. Input traffic
> > is 100% line rate.
> > >
> > > Different tb period and tb credits, therefore different output rate,
> are tried:
> > 25%, 50%, 75%, 90% and 100% the lineal rate. (The output for subport is
> Tb credits
> > per period / Tb period.)
> > > The traffic is injected change subport value random.
> > >
> > > Other parameters are same before tests and they don't change here.
> > >
> > > Cmdline: ./examples/qos_sched/build/qos_sched -c 0xe -n 4 -- --pfc
> > "0,1,2,3,3" --cfg "/root/profile_sched_pipe_1.cfg"
> > >
> > > The result is this table:
> > >
> > >
> > > +-----------------------+----------------------+
> > > | Subport output rate | Subport output rate |
> > > | (% line rate) | (Mpps) |
> > > +-----------+-----------+----------+-----------+
> > > | Expected | Actual | Expected | Actual |
> > > +-----------+-----------+----------+-----------+
> >
> > This table is empty.
> >
> > >
> > > Signed-off-by: Xiaonan Zhang <xiaonanx.zhang@intel.com>
> >
> > It seems that this test report is not relevant.
> > It will be ignored in the commit message. Sorry
>
>
next prev parent reply other threads:[~2015-04-02 22:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-01 2:33 Cunming Liang
2015-04-01 2:50 ` Zhang, Helin
2015-04-01 6:10 ` Zhang, XiaonanX
2015-04-01 19:51 ` Thomas Monjalon
2015-04-02 1:44 ` Liang, Cunming
2015-04-02 22:18 ` Stephen Hemminger [this message]
2015-04-02 1:52 ` Zhang, XiaonanX
2015-04-01 19:53 ` Thomas Monjalon
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=CAOaVG17Let-pZyWuqBipa97jZh-V7h7i5CLPF+4DrM3ShoDVEA@mail.gmail.com \
--to=stephen@networkplumber.org \
--cc=cunming.liang@intel.com \
--cc=dev@dpdk.org \
/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).