test suite reviews and discussions
 help / color / mirror / Atom feed
From: "Xu, Qian Q" <qian.q.xu@intel.com>
To: "Tu, LijuanX A" <lijuanx.a.tu@intel.com>,
	"Pei, Yulong" <yulong.pei@intel.com>,
	"Liu, Yong" <yong.liu@intel.com>, "dts@dpdk.org" <dts@dpdk.org>
Subject: Re: [dts] [PATCH]tests vf_port_start_stop: update test case
Date: Fri, 26 Feb 2016 06:35:25 +0000	[thread overview]
Message-ID: <82F45D86ADE5454A95A89742C8D1410E031EEE67@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <38D041F150D4184C8114E499040E62340727F61D@shsmsx102.ccr.corp.intel.com>

In fact, maybe we can't call it as an issue, it's a DPDK behavior. Because DPDK has a state that port is ready to RX/TX but not start Polling, so it's a state that Linux driver don't have, then we can't take Linux driver's behavior as reference. 

Thanks
Qian


-----Original Message-----
From: Tu, LijuanX A 
Sent: Friday, February 26, 2016 2:22 PM
To: Pei, Yulong; Liu, Yong; dts@dpdk.org; Xu, Qian Q
Subject: RE: [dts][PATCH]tests vf_port_start_stop: update test case

OK ,I Will verify Rx-errors, except fortville

> -----Original Message-----
> From: Pei, Yulong
> Sent: Friday, February 26, 2016 2:16 PM
> To: Tu, LijuanX A; Liu, Yong; dts@dpdk.org; Xu, Qian Q
> Subject: RE: [dts][PATCH]tests vf_port_start_stop: update test case
> 
> Hi Lijuan,
> 
> I think that maybe we keep checking Rx-errors and ignore this issue 
> for Fortville NIC and regard it as a known issue is better.
> 
> Best Regards
> Yulong Pei
> 
> -----Original Message-----
> From: Tu, LijuanX A
> Sent: Friday, February 26, 2016 1:13 PM
> To: Liu, Yong <yong.liu@intel.com>; dts@dpdk.org; Pei, Yulong 
> <yulong.pei@intel.com>; Xu, Qian Q <qian.q.xu@intel.com>
> Cc: Tu, LijuanX A <lijuanx.a.tu@intel.com>
> Subject: [dts][PATCH]tests vf_port_start_stop: update test case
> 
> Forwarding checking RX-packets, RX-Bytes, Tx-packets, Tx-bytes, Do not 
> checking Rx-errors fortville NIC:
>     when not start, the port is ready to RX but NOT RX packets,
>     if you send 119 packets at 64B, then it will be RXed at the NIC's 
> hardware buffer
>     if the buffer is full, it will show in RX-errors
>     so we do not verify Rx-errors.
> 
> Signed-off-by: Lijuan Tu <lijuanx.a.tu@intel.com>
> ---
>  tests/TestSuite_vf_port_start_stop.py | 48 
> ++++++++++++++++++++++-----
> --------
>  1 file changed, 30 insertions(+), 18 deletions(-)
> 
> diff --git a/tests/TestSuite_vf_port_start_stop.py
> b/tests/TestSuite_vf_port_start_stop.py
> index 0cc7ffd..17aa589 100644
> --- a/tests/TestSuite_vf_port_start_stop.py
> +++ b/tests/TestSuite_vf_port_start_stop.py
> @@ -114,11 +114,19 @@ class TestVfPortStartStop(TestCase):
>          testpmd.execute_cmd('port stop all')
>          testpmd.execute_cmd('clear port stats all')
> 
> -    def check_port_start_stop(self, testpmd, times=10):
> +    def check_port_start_stop(self, testpmd, times=1000):
>          """
>          VF port start/stop several times , check if it work well.
>          """
> +        port_id_0 = 0
> +        port_id_1 = 1
> +
>          for i in range(times):
> +            vf0_stats = self.vm0_testpmd.get_pmd_stats(port_id_0)
> +            b_vf0_rx_pkts, b_vf0_rx_bytes = vf0_stats['RX-packets'],
> vf0_stats['RX-bytes']
> +            vf1_stats = self.vm0_testpmd.get_pmd_stats(port_id_1)
> +            b_vf1_tx_pkts, b_vf1_tx_bytes = vf1_stats['TX-packets'], 
> + vf1_stats['TX-bytes']
> +
>              out = testpmd.execute_cmd('port start all')
>              self.verify("Checking link statuses" in out, "ERROR: port 
> start all")
>              testpmd.execute_cmd('start') @@ -127,22 +135,20 @@ class
> TestVfPortStartStop(TestCase):
>              out = testpmd.execute_cmd('port stop all')
>              self.verify("Checking link statuses" in out, "ERROR: port 
> stop all")
> 
> -        port_id_0 = 0
> -        port_id_1 = 1
> -        vf0_stats = self.vm0_testpmd.get_pmd_stats(port_id_0)
> -        vf1_stats = self.vm0_testpmd.get_pmd_stats(port_id_1)
> -
> -        vf0_rx_cnt = vf0_stats['RX-packets']
> -        self.verify(vf0_rx_cnt != 0, "no packet was received by
> vm0_VF0")
> -
> -        vf0_rx_err = vf0_stats['RX-errors']
> -        self.verify(vf0_rx_err == 0, "vm0_VF0 rx-errors")
> -
> -        vf1_tx_cnt = vf1_stats['TX-packets']
> -        self.verify(vf1_tx_cnt != 0, "no packet was transmitted by
> vm0_VF1")
> -
> -        vf1_tx_err = vf1_stats['TX-errors']
> -        self.verify(vf1_tx_err == 0, "vm0_VF0 tx-errors")
> +            vf0_stats = self.vm0_testpmd.get_pmd_stats(port_id_0)
> +            c_vf0_rx_pkts, c_vf0_rx_bytes = vf0_stats['RX-packets'],
> vf0_stats['RX-bytes']
> +            vf1_stats = self.vm0_testpmd.get_pmd_stats(port_id_1)
> +            c_vf1_tx_pkts, c_vf1_tx_bytes = vf1_stats['TX-packets'], 
> + vf1_stats['TX-bytes']
> +
> +            #Fortville NIC :when not start, the port is ready to RX
> but NOT RX packets,
> +            #if you send  packets , then it will be RXed at the NIC's
> hardware buffer
> +            #if buffer is full ,it will show RX-errors
> +            #so, we do not check RX-errors
> +            #compare vf0 RX-packets RX-bytes ,vf1 Tx-packets TX-bytes
> +            self.verify(c_vf0_rx_pkts > b_vf0_rx_pkts, "Packets
> received error")
> +            self.verify(c_vf0_rx_bytes > b_vf0_rx_bytes, "Bytes
> received error")
> +            self.verify(c_vf1_tx_pkts > b_vf1_tx_pkts, "Packets
> forwarding error")
> +            self.verify(c_vf1_tx_bytes > b_vf1_tx_bytes, "Bytes 
> + forvwarding error")
> 
>      def setup_1pf_2vf_1vm_env(self, driver='default'):
> 
> @@ -215,11 +221,17 @@ class TestVfPortStartStop(TestCase):
> 
>          self.vm0_testpmd = PmdOutput(self.vm_dut_0)
>          self.vm0_testpmd.start_testpmd(VM_CORES_MASK)
> +
> +        self.vm0_testpmd.execute_cmd('port stop all')
> +        self.vm0_testpmd.execute_cmd('port config all crc-strip on')
> +        self.vm0_testpmd.execute_cmd('port start all')
>          self.vm0_testpmd.execute_cmd('set fwd mac')
> +#        self.vm0_testpmd.execute_cmd('start')
> 
>          time.sleep(2)
> 
> -        dst_mac = self.vm_dut_0.get_mac_address(self.vm0_dut_ports[0])
> +        port_id_0 = 0
> +        dst_mac = self.vm0_testpmd.get_port_mac(port_id_0)
>          self.send_and_verify(dst_mac, self.vm0_testpmd)
> 
>      def tear_down(self):
> --
> 1.9.3

  reply	other threads:[~2016-02-26  6:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  5:13 Lijuan Tu
2016-02-26  6:15 ` Pei, Yulong
2016-02-26  6:22   ` Tu, LijuanX A
2016-02-26  6:35     ` Xu, Qian Q [this message]
2016-02-26  6:54       ` Tu, LijuanX A

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=82F45D86ADE5454A95A89742C8D1410E031EEE67@shsmsx102.ccr.corp.intel.com \
    --to=qian.q.xu@intel.com \
    --cc=dts@dpdk.org \
    --cc=lijuanx.a.tu@intel.com \
    --cc=yong.liu@intel.com \
    --cc=yulong.pei@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).