[dpdk-test-report]|SUCCESS | dpdk-next-net-intel|f649fd010f| Intel-Testing

[dpdk-test-report]|SUCCESS | dpdk-next-net-intel|f649fd010f| Intel-Testing

[sys_stv]

[-- Attachment #1: Type: text/plain, Size: 6822 bytes --]


Test-Label: intel-Testing
Test-Status: SUCCESS 
_Testing PASS 

DPDK git repo: dpdk-next-net-intel

commit f649fd010f2dd3a97e15f2ef106440a79f6c95fb
Author: Ivan Malov <ivan.malov@arknetworks.am>
Date:   Wed Apr 12 17:57:57 2023 +0400

    net/sfc: stop misuse of Rx ingress m-port metadata on EF100
    
    The driver supports representor functionality. In it,
    packets coming from VFs to the dedicated back-end Rx
    queue get demultiplexed into front-end Rx queues of
    representor ethdevs as per the per-packet metadata
    indicating logical HW ingress ports. On transmit,
    packets are provided with symmetrical metadata
    by front-end Tx queues, and the back-end queue
    transforms the data into so-called Tx override
    descriptors. These let the packets bypass flow
    lookup and go directly to the represented VFs.
    
    However, in the Rx part, the driver extracts
    the said metadata on every HW Rx queue, that
    is, not just on the one used by representors.
    Doing so leads to a buggy behaviour. It is
    revealed by operating testpmd as follows:
    
    dpdk-testpmd -a 0000:c6:00.0 -a 0000:c6:00.1 -- -i
    
    testpmd> flow create 0 transfer pattern port_representor \
     port_id is 0 / end actions port_representor port_id 1 / end
    Flow rule #0 created
    
    testpmd> set fwd io
    testpmd> start tx_first
    
    testpmd> flow destroy 0 rule 0
    Flow rule #0 destroyed
    
    testpmd> stop
    
      ---------------------- Forward statistics for port 0  -----------------
      RX-packets: 19196498       RX-dropped: 0             RX-total: 19196498
      TX-packets: 19196535       TX-dropped: 0             TX-total: 19196535
      -----------------------------------------------------------------------
    
      ---------------------- Forward statistics for port 1  -----------------
      RX-packets: 19196503       RX-dropped: 0             RX-total: 19196503
      TX-packets: 19196530       TX-dropped: 0             TX-total: 19196530
      -----------------------------------------------------------------------
    
    In this scenario, two physical functions of the adapter
    do not have any corresponding "back-to-back" forwarder
    on peer host. Packets transmitted from port 0 can only
    be forwarded to port 1 by means of a special flow rule.
    
    The flow rule indeed works, but destroying it does not
    stop forwarding. Port statistics carry on incrementing.
    
    Also, it is apparent that forwarding in the opposite
    direction must not have worked in this case as the
    flow is meant to target only one of the directions.
    
    Because of the bug, the first 32 mbufs received
    as a result of the flow rule operation have the
    said metadata present. In io mode, testpmd does
    not tamper with mbufs and passes them directly
    to transmit path, so this data remains in them
    instructing the PMD to override destinations
    of the packets via Tx option descriptors.
    
    Expected behaviour is as follows:
    
      ---------------------- Forward statistics for port 0  -----------------
      RX-packets: 0              RX-dropped: 0             RX-total: 0
      TX-packets: 15787496       TX-dropped: 0             TX-total: 15787496
      -----------------------------------------------------------------------
    
      ---------------------- Forward statistics for port 1  -----------------
      RX-packets: 15787464       RX-dropped: 0             RX-total: 15787464
      TX-packets: 32             TX-dropped: 0             TX-total: 32
      -----------------------------------------------------------------------
    
    These figures show the rule work only for one direction.
    Also, removing the flow shall cause forwarding to cease.
    
    Provided patch fixes the bug accordingly.
    
    Fixes: d0f981a3efd8 ("net/sfc: handle ingress mport in EF100 Rx prefix")
    Cc: stable@dpdk.org
    
    Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
    Reviewed-by: Andy Moreton <amoreton@xilinx.com>
    Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

Testing Summary : 18 Case Done, 18 Successful, 0 Failures

Testbed #1: 9 Case Done, 9 Successful, 0 Failures 
	* Test result details:
	  +-------------+---------------------------+-------+
	  | suite       | case                      | status|
	  +-------------+---------------------------+-------+
	  | asan_smoke  | test_rxtx_with_ASan_enable| passed|
	  | pf_smoke    | test_pf_jumbo_frames      | passed|
	  | pf_smoke    | test_pf_rss               | passed|
	  | pf_smoke    | test_pf_tx_rx_queue       | passed|
	  | vf_smoke    | test_vf_jumbo_frames      | passed|
	  | vf_smoke    | test_vf_rss               | passed|
	  | vf_smoke    | test_vf_tx_rx_queue       | passed|
	  | virtio_smoke| test_virtio_loopback      | passed|
	  | virtio_smoke| test_virtio_pvp           | passed|
	  +-------------+---------------------------+-------+
	* Environment:
	  OS : Ubuntu 20.04.5 LTS       
	  Kernel : 5.8.0-63-generic         
	  GCC : 9.4.0-1ubuntu1~20.04.1        
	  NIC : Ethernet Controller E810-C for SFP         
	  Target : x86_64-native-linuxapp-gcc      

Testbed #2: 9 Case Done, 9 Successful, 0 Failures 
	* Test result details:
	  +-------------+---------------------------+-------+
	  | suite       | case                      | status|
	  +-------------+---------------------------+-------+
	  | asan_smoke  | test_rxtx_with_ASan_enable| passed|
	  | pf_smoke    | test_pf_jumbo_frames      | passed|
	  | pf_smoke    | test_pf_rss               | passed|
	  | pf_smoke    | test_pf_tx_rx_queue       | passed|
	  | vf_smoke    | test_vf_rss               | passed|
	  | vf_smoke    | test_vf_tx_rx_queue       | passed|
	  | vf_smoke    | test_vf_jumbo_frames      | n/a   |
	  | virtio_smoke| test_virtio_loopback      | passed|
	  | virtio_smoke| test_virtio_pvp           | passed|
	  +-------------+---------------------------+-------+
	* Environment:
	  OS : Ubuntu 20.04.5 LTS       
	  Kernel : 5.13.0-30-generic         
	  GCC : 9.4.0-1ubuntu1~20.04.1        
	  NIC : Ethernet Controller XL710 for 40GbE QSFP+         
	  Target : x86_64-native-linuxapp-gcc      

TestPlan:
	   pf_smoke: http://git.dpdk.org/tools/dts/tree/test_plans/pf_smoke_test_plan.rst
	   vf_smoke: http://git.dpdk.org/tools/dts/tree/test_plans/vf_smoke_test_plan.rst
	   asan_smoke: http://git.dpdk.org/tools/dts/tree/test_plans/asan_smoke_test_plan.rst

TestSuite:
	   pf_smoke: http://git.dpdk.org/tools/dts/tree/tests/TestSuite_pf_smoke.py
	   vf_smoke: http://git.dpdk.org/tools/dts/tree/tests/TestSuite_vf_smoke.py
	   virtio_smoke: http://git.dpdk.org/tools/dts/tree/tests/TestSuite_virtio_smoke.py
	   asan_smoke: http://git.dpdk.org/tools/dts/tree/tests/TestSuite_asan_smoke.py


DPDK STV team