[dts] [PATCH V1] test_plans/scatter: test plan revise

Wan, Zhe zhe.wan at intel.com
Thu Apr 11 08:38:27 CEST 2019


Hi Lijuan,
About the addition of '--tx-offloads=0x00008000', the background is DPDK-5618 (https://jira.devtools.intel.com/browse/DPDK-5618).
The test plan didn't updated accordingly.

commit 3743153fac89b821959fbb882058bf81177b07e7.
Author: xu,gang <gangx.xu at intel.com>
Date:   Tue Jul 10 10:49:58 2018 +0800

    tests/scatter: fix selected wrong vector path on ixgbe

    When no tx offload enabled, ixgbe will chose vector path which can not
    support scatter. After enabling DEV_TX_OFFLOAD_MULTI_SEGS options, can
    avoid this problem.

    Signed-off-by: xu,gang <gangx.xu at intel.com>

https://mails.dpdk.org/archives/dts/2018-July/004208.html

This TX offload capability defined in DPDK code 'dpdk/lib/librte_ethdev/rte_ethdev.h'
#define DEV_TX_OFFLOAD_MULTI_SEGS	0x00008000    /**< Device supports multi segment send. */


Thanks!
BR,
Wan,Zhe

-----Original Message-----
From: Tu, Lijuan 
Sent: Thursday, April 04, 2019 1:30 AM
To: Wan, Zhe <zhe.wan at intel.com>; dts at dpdk.org
Cc: Wan, Zhe <zhe.wan at intel.com>
Subject: RE: [dts] [PATCH V1] test_plans/scatter: test plan revise

Hi zhe, 

Could you please kindly add some interpretation about why is --tx-offloads=0x00008000 ?

thanks

> -----Original Message-----
> From: dts [mailto:dts-bounces at dpdk.org] On Behalf Of Zhe
> Sent: Friday, March 29, 2019 9:30 AM
> To: dts at dpdk.org
> Cc: Wan, Zhe <zhe.wan at intel.com>
> Subject: [dts] [PATCH V1] test_plans/scatter: test plan revise
> 
> From: Zhe Wan <zhe.wan at intel.com>
> 
> Signed-off-by: Zhe Wan <zhe.wan at intel.com>
> ---
>  test_plans/scatter_test_plan.rst | 27 ++++++++++++---------------
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/test_plans/scatter_test_plan.rst
> b/test_plans/scatter_test_plan.rst
> index cf5e1e5..ed1aaaa 100644
> --- a/test_plans/scatter_test_plan.rst
> +++ b/test_plans/scatter_test_plan.rst
> @@ -72,15 +72,15 @@ the CRC from the packet before returning it.
>  As a whole, the following packet lengths (CRC included) must be 
> tested to check all packet memory configurations:
> 
> -#. packet length < mbuf data buffer size
> +1) packet length < mbuf data buffer size
> 
> -#. packet length = mbuf data buffer size
> +2) packet length = mbuf data buffer size
> 
> -#. packet length = mbuf data buffer size + 1
> +3) packet length = mbuf data buffer size + 1
> 
> -#. packet length = mbuf data buffer size + 4
> +4) packet length = mbuf data buffer size + 4
> 
> -#. packet length = mbuf data buffer size + 5
> +5) packet length = mbuf data buffer size + 5
> 
>  In cases 1) and 2), the hardware RX engine stores the packet data and 
> the CRC  in a single buffer.
> @@ -101,21 +101,18 @@ Assuming that ports ``0`` and ``1`` of the test 
> target are directly connected  to a Traffic Generator, launch the 
> ``testpmd`` application with the following
>  arguments::
> 
> -  ./build/app/testpmd -cffffff -n 3 -- -i --rxd=1024 --txd=1024 \
> -  --burst=144 --txpt=32 --txht=8 --txwt=8 --txfreet=0 --rxfreet=64 \
> -  --mbcache=200 --portmask=0x3 --mbuf-size=1024
> +  ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x6 -n 4 \
> +  -- -i --mbcache=200 --mbuf-size=2048 --portmask=0x1 \
> +  --max-pkt-len=9000 --port-topology=loop --tx-offloads=0x00008000
> 
>  The -n command is used to select the number of memory channels. It 
> should match  the number of memory channels on that setup.
> 
> -Setting the size of the mbuf data buffer to 1024 makes 1025-bytes 
> input packets -(CRC included) and larger packets to be stored in two 
> buffers by the hardware -RX engine.
> -
> -Test Case: Mbuf 1024 traffic
> +Test Case: Scatter Mbuf 2048
>  ============================
> 
>  Start packet forwarding in the ``testpmd`` application with the 
> ``start`` command.
> -Send 5 packets of lengths (CRC included) 1023, 1024, 1025, 1028, and 1029.
> +Send 5 packets,the lengths are mbuf-size + offset (CRC included).
> +The offset are -1, 0, 1, 4, 5 respectively.
>  Check that the same amount of frames and bytes are received back by 
> the Traffic -Generator from its port connected to the target's port 1.
> +Generator from it's port connected to the target's port 1.
> --
> 1.8.3.1



More information about the dts mailing list