[dpdk-dev] mlx5 flow create/destroy behaviour

Legacy, Allain Allain.Legacy at windriver.com
Tue Mar 28 14:42:05 CEST 2017


Hi,
I am setting up an experiment to gauge the usability of the flow API and the flow marking behavior of the CX4.   I am working from v17.02.   I am seeing some unpredictable behavior that I am unsure of the cause. 

This is the layout of the test:
   
   2 x CX4 (15b3:1015) 
      + 1 port used on each
   A test application with 1 core, and 1 queue/port
   Traffic generator attached to each port
      + 500 unique src+dst MAC address combinations sent from each port
      + All traffic is VLAN tagged (1 VLAN per port)

The test application examines packets as they are received on each port.  It sets up flow rules and calls rte_flow_create() for each new layer2 flow that it observes.    The flow patterns are of the form ETH+VLAN+END where ETH matches src+dst+type=vlan, VLAN matches the port's VLAN ID.  The flow actions are of the form MARK+QUEUE+END where MARK assigns a unique integer to each flow and, and QUEUE assigns the flow to queue_id=0 (since the test app only has 1 queue per port).

Once the flows are setup, the application then checks that ingress packets are properly marked with the intended unique integer specified in the MARK action.  

The traffic is run for a short period of time and then stopped.  Once the traffic is stopped the application removes the flow rules by calling rte_flow_destroy().    There is no guarantee that the order of the destroys resembles in any way the order of the creates.   (I mention this because of this warning in rte_flow.h:  "This function is only guaranteed to succeed if handles are destroyed in reverse order of their creation.").   All of the calls to rte_flow_destroy() succeed. 

When I run this test after the NIC has been reset there are no issues.  All calls to rte_flow_create()/rte_flow_destroy() succeed and all packets have a valid mark ID that corresponds to the unique integer assigned to that src+dst+vlan grouping.    

The problem happens when I run this test for a second or third time without first resetting the NIC.  On subsequent test runs I still see no errors in create/destroy API calls but packets are no longer marked by the hardware.  In some test runs none of the flows have valid mark id values, and other test runs have some percentage of flows with valid mark id values while others do not.   The behavior seems inconsistent but if I reset the NIC the behavior goes back to working for 1 test run and then starts behaving incorrectly again on subsequent runs.

I should note that in subsequent test runs the MAC addresses are the same as previous runs, and but the mapping from unique integer to src+dst+vlan are different each time.  

Is this behavior consistent with your experience using the device and/or API?


Regards,
Allain


Allain Legacy, Software Developer
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
 





More information about the dev mailing list