From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8CC30A0565; Mon, 23 Mar 2020 14:00:21 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B73A1C065; Mon, 23 Mar 2020 14:00:20 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id F35F11C044 for ; Mon, 23 Mar 2020 14:00:17 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 57D175C0262; Mon, 23 Mar 2020 09:00:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 23 Mar 2020 09:00:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=IMsYELv7VSuRTnr5b1YgtX9KevZIMGLzdJq6xTstmcU=; b=av/A66M6VM8p miQer1F+U1/r/3Dn3E6up2XP+sW/kHE+qwcWncED1d12d9jMC2PGvZGc5uIzWbnc 9f41I9QFl+vNsexbdS8S+e45t4J4ISXY+7SQEy3ClzJRT3qAflmiiXRZM1VIGYhC nwOQpUaNuCaE9kQ2p3nD/e3o1oSEU5k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=IMsYELv7VSuRTnr5b1YgtX9KevZIMGLzdJq6xTstm cU=; b=B7d+56N2/Lr8WF7LWIEchRUVVELzbe49kTUCetejyPFc94azQ4b8cn0mK wLVLvPm4ElIJh6TWNQFEk4ZM5OZEVxTiwhFbBPCIn5iJUxIFHh0m0DRBd2TM2wV2 Lrmgaokpy3mX4bCgv+zt+0Ae0QibODVGp+ZCwXKEZgUAwJZhR90QRin6JqFz7Q1u 3OZpNDtTRBVWNzZPg/nes++ZFdNrNi0B3+Dvrg9RB57lYVnlMripcMUkE6Y+vk6r aW0q3HXtKNFFCdvRPw0BxDxKE1qBgqdX5MeZRrPLD+oXQxu+ocJmUuuTTNDRgSV1 Bn23OEMifVRd9DJ9Ee4ZZf3qpNRWA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegkedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 19E213062A92; Mon, 23 Mar 2020 09:00:16 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Wisam Monther Cc: dpdk-dev , Matan Azrad , Raslan Darawsheh Date: Mon, 23 Mar 2020 14:00:14 +0100 Message-ID: <2643636.88bMQJbFj6@xps> In-Reply-To: References: <1584452772-31147-1-git-send-email-wisamm@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] app/test-flow-perf: add rte_flow perf app 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 23/03/2020 12:41, Wisam Monther: > From: Jerin Jacob > > On Mon, Mar 23, 2020 at 3:23 PM Wisam Monther wrote: > > > From: Jerin Jacob > > > > On Fri, Mar 20, 2020 at 5:21 PM Thomas Monjalon wrote: > > > > > 20/03/2020 07:49, Jerin Jacob: > > > > > > On Tue, Mar 17, 2020 at 7:16 PM Wisam Jaddo wrote: > > > > > > > > > > > > Thanks for this application. Useful stuff. > > > > > > > > > > > > > > > > > > > > Introducing new application for rte_flow performance testing. > > > > > > > The application provide the ability to test insertion rate of > > > > > > > specific rte_flow rule, by stressing it to the NIC, and > > > > > > > calculate the insertion rate. > > > > > > > > > > > > > > It also provides packet per second measurements after the > > > > > > > insertion operation is done. > > > > > > > > > > > > > > The application offers some options in the command line, to > > > > > > > configure which rule to apply. > > > > > > > > > > > > > > After that the application will start producing rules with > > > > > > > same pattern but increasing the outer IP source address by 1 > > > > > > > each time, thus it will give different flow each time, and all > > > > > > > other items will have open masks. > > > > > > > > > > > > > > The current design have single core insertion rate. > > > > > > > In the future we may have a multi core insertion rate > > > > > > > measurement support in the app. > > > > > > > > > > > > If I understand correctly, > > > > > > # On the main thread, this application first check the flow > > > > > > insertion performance # and then start the worker thread for > > > > > > packet forwarding. > > > > > > Why this application testing the packet forwarding?, We already > > > > > > have testpmd for that. > > > > > > > > > > I think it is interesting to measure forwarding performance when > > > > > million of flow rules are in effect. > > > > > > > > The rules are applied to the HW CAM, Right? > > > > Do you see any performance difference? > > > > > > > > > > Yes, there are applied to HW, > > > > > > OK.IMO, it is better to introduce the command-line argument to > > disable/enable packet forwarding. > > That will enable if someone needs to test only flow insertion performance to > > avoid the IO setup. > > > > Sure, we can have the forwarding enabled by default, and I'll add --disable-fwd > To command line options, it looks reasonable to have it, I agree In general I prefer things disabled by default. Option --test-fwd makes more sense and can accept some forwarding options. > > > No not really, I still didn't test the impact of performance yet. > > > Moreover it's interesting to see such results and the impact on > > > performance, Also to see the rules are still matching after all > > > Millions of insertion and millions of packets Sending/receiving. > > > > > > > > > > IMO, This application needs to focus only on > > > > > > - Insertion performance > > > > > > - Deletion performance > > > > > > - IMO, it is better to add a framework for the profile where the > > > > > > first version of this application can define common a set of > > > > > > ITEMS and set of ACTION and later others can extend it. > > > > > > And the framework can run over all the profiles and spit out the > > > > > > insertion and deletion performance. > > > > > > > > > > What do you call a profile? Is it a set of rules? > > > > > > > > set of rules and/or actions. > > > > > > > > > I think this first version is proposing rules customization with > > parameters. > > > > > > > > Just that it better to have a framework where one can easily add new > > > > profiles and test various combos. IMO, Cascade rules take more > > > > insertion time. > > > > > > > > > Note: I prefer a non-interactive application for performance testing. > > > > > > > > Me too. Command-line is fine. > > > > > > > > > > For this version I'm aiming to have the command line options to decide the > > profile. > > > For example: > > > . /flow-perf -n 4 -w 0000:03:00.1,dv_flow_en=1 -- --ingress --ether > > > --ipv4 --udp --vxlan-gpe --queue --mark Will mean 4 Million rules of: > > > Flow create 0 ingress pattern eth / ipv4 src is / udp / vxlan-gpe > > > / end actions mark id 1 / queue < QUEUE _ID> / end > > > > Ok. The syntax looks good. I think we can add a number of rules as well in > > command like instead of hardcoding to 4Millon. > > Sure we can have it also > BTW, I'm planning to have a file under "user_paramters.h" > This file for other specific fields such as: > /** Flows count & iteration size **/ > #define FLOWS_COUNT 4000000 > #define ITERATION_SIZE 100000 Please make flows count a variable which can be changed with option. > > And what about the flow deletion performance case? > > I agree we should have it as well in this application, > I plan it to do it as well Great, thanks