From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B7D3A0548; Tue, 27 Apr 2021 13:11:53 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1E8A44014E; Tue, 27 Apr 2021 13:11:53 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id C162541226 for ; Tue, 27 Apr 2021 13:11:51 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 435155804EF; Tue, 27 Apr 2021 07:11:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 27 Apr 2021 07:11:51 -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=fm1; bh= McMbujyK9Hacu0QyhyCNnXFfSQjg3EaeQLeZbQDqiKY=; b=OWq3OX63bdWDcG13 aRkR7YN0CBSkMFYAXLTR4ptBC87u5Xqr5IfblJzWPiSm2zZhk3tCXiYX1e0erLJ8 df631f4sfyDZwtPaiQ+TJMVAlWaWzbB0BT6ghk2i8rxKYWK8fqbH98E03NafNo48 wC53KLVPdr9e1PoVWohZmaCWnz0AugUtrVK5Ehz/wPWQ3iYXthJL9AM8aNTrIvjo aKqjFV/2c04o88p1KCvkdVTRLW7kGvCNHQtBSss5ur/bPv1lE0+qlyqSQXZZ5vhA TZZSVLZAuHx7IxaR9qDdY3FNTAcVUXL61fgHOKcoqE/3oHFhxfZHWXGfitxprQmM vSYfIg== 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=McMbujyK9Hacu0QyhyCNnXFfSQjg3EaeQLeZbQDqi KY=; b=LHnfX9FdT69uDSZZeYLnoSTsu9MdPkU69CWYeAL076t9Xnyxxzfy3M0lv MTqHESyixPpvQvMSH5nnJTOnsblTuIKXKlHqZvB4kn7jfloUdDt1y4LYTnpj4G9c bnf1UVBIrPpB7ciWghfJEaPSN92Pf/15czKU7mceXncL6qKHVcRyhWT7H3S8vjPa S1RNjiRDXx0+DGR4lOroNiqNh9gDauiqQ0X87BshsiXQ9vE/DE2wVl4OFfwDBfKL rPXRrYCAFyN/IU7zw/LUYqk5tgBUYjCi3+BeyQ0gU8Tl3iA4PTJ9X++PWvqQEf9u WCR5B93fk/R+nogGOuj/Le468FAHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvtddgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgfevhedtheejvdegvdegffeljeehueeftdeihefffeelhfeivdeg teffueekfefgnecuffhomhgrihhnpeguphgukhdrohhrghdpghhithhhuhgsrdgtohhmne cukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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; Tue, 27 Apr 2021 07:11:47 -0400 (EDT) From: Thomas Monjalon To: "Yigit, Ferruh" , Honnappa Nagarahalli , Stephen Hemminger , Jerin Jacob , "Ananyev, Konstantin" Cc: Kathleen Capella , "dev@dpdk.org" , Dharmik Thakkar , Ruifeng Wang , "david.marchand@redhat.com" , "Richardson, Bruce" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "Ananyev, Konstantin" , Stephen Hemminger , nd Date: Tue, 27 Apr 2021 13:11:43 +0200 Message-ID: <4144195.lBnvlMlemC@thomas> In-Reply-To: References: <81781e97-735c-f584-4148-ff07dedc5cb4@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] L3fwd mode in testpmd X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 27/04/2021 11:57, Ananyev, Konstantin: > From: Yigit, Ferruh > > On 4/26/2021 9:46 PM, Honnappa Nagarahalli wrote: > > >>>>>>>>>>>> On Thu, Mar 11, 2021 at 12:01 AM Honnappa > > >>>>>>>>>>>> Nagarahalli wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Hello, > > >>>>>>>>>>>>> Performance of L3fwd example application > > >>>>>>>>>>>>> is one of the key > > >>>>>>>>>>>> benchmarks in DPDK. However, the application does > > >>>>>>>>>>>> not have many debugging statistics to understand the > > >>>>>>>>>>>> performance issues. We have added L3fwd as another > > >>>>>>>>>>>> mode/stream to testpmd which provides > > >>>>>>>>>> enough > > >>>>>>>>>>>> statistics at various levels. This has allowed us to > > >>>>>>>>>>>> debug the performance issues effectively. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> There is more work to be done to get it to > > >>>>>>>>>>>>> upstreamable state. I am > > >>>>>>>>>>>> wondering if such a patch is helpful for others and > > >>>>>>>>>>>> if the community would be interested in taking a > > >>>>>>>>>>>> look. Please let me know > > >>>>>>>>> what you think. > > >>>>>>>>>>>> > > >>>>>>>>>>>> We are using app/proc-info/ to attach and analyze > > >>>>>>>>>>>> the > > >>>>> performance. > > >>>>>>>>>>>> That helps to analyze the unmodified application. I > > >>>>>>>>>>>> think, if something is missing in proc-info app, in > > >>>>>>>>>>>> my opinion it is better to enhance proc-info so that > > >>>>>>>>>>>> it can help other third-party > > >>>>>>> applications. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Just my 2c. > > >>>>>>>>>>> Thanks Jerin. We will explore that. > > >>>>>>>>>> > > >>>>>>>>>> I agree it is dangerous to rely too much on testpmd for > > >> everything. > > >>>>>>>>>> Please tell us what in testpmd could be useful out of it. > > >>>>>>>>>> > > >>>>>>>>> Things that are very helpful in testpmd are: 1) HW > > >>>>>>>>> statistics from the NIC 2) Forwarding stats 3) Burst stats > > >>>>>>>>> (indication of headroom > > >>>>>>>>> availability) 4) Easy to set parameters like RX and TX > > >>>>>>>>> queue depths (among others) without having to recompile. > > >>>>>>>> > > >>>>>>>> [Kathleen Capella] > > >>>>>>>> Thank you for the suggestion of app/proc-info. I've tried it > > >>>>>>>> out with l3fwd and see that it does have the HW stats from > > >>>>>>>> the NIC and the forwarding > > >>>>>>> stats. > > >>>>>>>> However, it does not have the burst stats testpmd offers, > > >>>>>>>> nor the > > >>>>>>> > > >>>>>>> One option to see such level of debugging would be to have > > >>>>>>> - Create a memzone in the primary process > > >>>>>>> - Application under test can update the stats in memzone based > > >>>>>>> on the code flow > > >>>>>>> - proc-info can read the counters updated by application under > > >>>>>>> test using the memzone object got through > > >> rte_memzone_lookup() > > >>>>>> Agreed. Currently, using app/proc-info does not provide this > > >>>>>> ability. We > > >>>>> cannot add this capability to app/proc-info as these stats would > > >>>>> be specific to L3fwd application. > > >>>>> > > >>>>> I meant creating generic counter-read/write infra via memzone to > > >>>>> not make it as l3fwd specific. > > >>>> Currently, app/proc-info is able to print the stats as they are standardized > > >> via the API. But for statistics that are generated in the application, they are > > >> very specific to that application. For ex: burst stats in testpmd are very > > >> specific to it and another application might implement the same in a very > > >> different manner. > > >>>> > > >>>> In needs to be something like the app/proc-info just needs to be a dumb > > >> displaying utility and the application has to do all the heavy lifting of copying > > >> the exact display strings to the memory. > > >>> > > >>> Yes. > > >>> > > >>>> > > >>>>>>> > > >>>>>>> Another approach will be using rte_trace()[1] for > > >>>>>>> debugging/tracing by adding tracepoints in l3fwd for such events. > > >>>>>>> It has a timestamp and the trace format is opensource trace > > >>>>>>> format(CTF(Common trace format)), so that we can use post > > >>>>>>> posting tools to analyze. > > >>>>>>> [1] > > >>>>>>> https://doc.dpdk.org/guides/prog_guide/trace_lib.html > > >>>>>> This is good for analyzing an incident. I think it is an > > >>>>>> overhead for > > >>>>> development purposes. > > >>>>> > > >>>>> Consider if one wants to add burst stats, one can add stats > > >>>>> increment under RTE_TRACE_POINT_FP, it will be emitted whenever > > >>>>> code flow through that path. Set of events of can be viewed in > > >>>>> trace viewer[1]. Would that be enough? > > >>>>> Adding traces to l3fwd can be upstreamed as it is useful for > > >>>>> others for debugging. > > >>>>> > > >>>>> [1] > > >>>>> https://github.com/jerinjacobk/share/blob/master/dpdk_trace.JPG > > >>>> This needs post processing of the trace info to derive the information, is it > > >> correct? For ex: for burst stats, there will be several traces generated > > >> collecting the number of packets returned by rte_eth_rx_burst which needs > > >> to be post processed. > > >>> > > >>> Or You can have an additional variable to acculate it. > > >>> > > >>>> Also, adding traces is equivalent to adding statistics in L3fwd. > > >>> > > >>> Yes. > > >>> > > >>> If the sole purpose only stats then it is better to add status in > > >>> l3fwd without performance impact. I thought some thing else. > > >>> > > >>>> > > >>>>>>> > > >>>>>>>> ability to easily change parameters without having to > > >>>>>>>> recompile, which helps reduce debugging time significantly. > > >>>> We will not be able to fix this above issue. > > >>> > > >>> It depends on what you want to debug. Trace can be disabled at runtime. > > >> > > >> > > >> DPDK has existing API's for application metrics but they are rarely used. > > >> > > >> Why not implement rte_metrics in l3fwd and proc-info? > > > This discussion has ended up as a stats discussion. But, we also need to be able to change the configurable parameters easily. > > > If we implement the stats and ability to change the configurable parameters, then it is essentially bringing in some of the capabilities from > > testpmd to the sample application. I think that will result in lot more code in the sample application and will make it complicated. > > > > > > Instead our proposal is to take L3fwd to testpmd and use all the infra code that testpmd provides. We see that this approach results in less > > amount of code added to DPDK overall. > > > > > > > Agree that it may help testing to have l3fwd support on the testpmd. > > > > Two concerns, > > 1) Testpmd already too complex. > > 2) Code duplication. > > > > For 1), if the l3fwd can be implemented in testpmd as new, independent > > forwarding mode, without touching rest of the testpmd, I think it can be OK. > > In fact, l3fwd is also quite big and complex: > $ wc -l examples/l3fwd/*.[h,c] |grep total > 6969 total > > Plus it will introduce extra dependencies (fib, lpm, hash, might-be acl?) > I am not sure it is a good idea to pull all these complexities into test-pmd. > I can't imagine that l3fwd app need ability to configure each and every > PMD parameter. > From my experience in l3fwd most of cycles are spent not in PMD itself, > but in actual packet processing: header parsing and checking, classification, > routing table lookup, etc. testpmd goal is to test the driver, not the libraries. > > Not sure how to address 2), also lets say we want to add new feature to l3fwd, > > where it should go, to the sample or to the testpmd? l3fwd is not targetted for testing. Maybe we just lack a new test application for routing libraries?