From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 6C7FC37AA for ; Tue, 28 Mar 2017 17:36:11 +0200 (CEST) Received: by mail-wm0-f52.google.com with SMTP id t189so1990913wmt.1 for ; Tue, 28 Mar 2017 08:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=fwSK5xFHdntLNyoYoSyCOrUGnrwa897IgRkarGIlOPk=; b=JcaQFlksEHfELZnzBz1vxYVuVlSt5UEB0qrGiR74Ae6CWi44xWzxxUrjLP2gjxiY2O 2IeO3RtfYDTEoH8LgKlBpZqgrsxnLPBz9E6kNW5dh5tVJszu8IBrM7mmagAdmAJ6zqzG yBvO85siw22k9VXw+oum+7nFm7w9doYNn3ztQJOiHRQ/ou/SjsRJ6Xd4vJR1ffFVpi1L FW+PCbpooz7HrGBbJ03C84WUu5UdeZDW2qBIFNbQGmgrUJD1YX2DWonxPwMeNGq9G/3y IqdCIPHBdfCqZob8XRiPcUXurL3QYNQlVhnq2/lLEXabRNWpBoc2JTl/IJHek7mN35Uv RnCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=fwSK5xFHdntLNyoYoSyCOrUGnrwa897IgRkarGIlOPk=; b=ZE0qXVwe8BONIUIh7tFWhrSsQp7REZwm8nHWHwYJaCMOgxAkkgHGh98tGjv1SsCkor tY6vtCpmgZldjAv16ybxzOx7MtKv5NuiC3GvsHIzXTOeIuZDxjH/p1Nit/5HBqcaD52b OVJOm34n0OtwQZaPWseNm6DCfg86ld/SLP/XrPgbtFeGJfpE0J7dC1yj9LKn3HUaBEGQ U0Fz7LA5Y1dkJLGjEpZIEn7/jbj0GrXa5iBghAMr4hmxOqkn8jjt/zi7O7FbFsswUkaw UZQGrT2BqLNPXRu1JXRJKTDWBFoKwSesa6416jjgS55yMrSBMB85cZNdI+C/+KO/9W68 k+8A== X-Gm-Message-State: AFeK/H1i130YZCjRZidfYvF35FQarpTFOYz2ZxY6Ezb0XXzv4Mtop4eaLX2d2eZxri6ArjKp X-Received: by 10.28.131.77 with SMTP id f74mr14975700wmd.109.1490715370939; Tue, 28 Mar 2017 08:36:10 -0700 (PDT) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id j77sm4100346wmj.3.2017.03.28.08.36.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 08:36:10 -0700 (PDT) Date: Tue, 28 Mar 2017 17:36:02 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Legacy, Allain" Cc: "Adrien Mazarguil (adrien.mazarguil@6wind.com)" , "dev@dpdk.org" , "Peters, Matt" Message-ID: <20170328153602.GC16796@autoinstall.dev.6wind.com> References: <70A7408C6E1BFB41B192A929744D8523968F8E2F@ALA-MBC.corp.ad.wrs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <70A7408C6E1BFB41B192A929744D8523968F8E2F@ALA-MBC.corp.ad.wrs.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] mlx5 flow create/destroy behaviour X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:36:11 -0000 Hi Allain, My attempt to reproduce it was a failure, may be I missed something, please see below, On Tue, Mar 28, 2017 at 12:42:05PM +0000, Legacy, Allain wrote: > 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). If I understand correctly, your application is adding 500 rules like: flow create 0 ingress pattern eth src is dst is / vlan vid is / end action mark id is / queue index 0 / end > 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. It is sending packets to verify this? > 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. What do you mean by "reset"? > 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. In mlx5 PMD rte_flow_destroy() always returns success as the destruction should never fail. Can you compile in debug mode (by setting CONFIG_RTE_LIBRTE_MLX5_DEBUG to "y")? Then you should have as many print for the creation rules than the destroyed ones. > 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? No I did not face such issue, the behavior was consistent, but I never tried to generate so many rules in the past. Thanks, -- Nélio Laranjeiro 6WIND