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 B2C60A0548; Mon, 26 Apr 2021 11:45:18 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7D57D41110; Mon, 26 Apr 2021 11:45:18 +0200 (CEST) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by mails.dpdk.org (Postfix) with ESMTP id 2D47A40140 for ; Mon, 26 Apr 2021 11:45:16 +0200 (CEST) Received: by mail-il1-f180.google.com with SMTP id c3so4878915ils.5 for ; Mon, 26 Apr 2021 02:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=z4iCmcpgVECWJRrqOWd//PjPSZ6hGngwh0fEJcxLSVs=; b=LbLCY1fyrdGN8X2E9ZzTvBEmU1EwQKcsp1lL8+uMKroitSOmfokMdshAyjvVFfTO0i a8Ytad1UqVR14GhnwAul89C/ITKJIf7PZ6DxKZAOYDR02u8SMdFxPO4UMyGOZQ5jaoUC gxsMFbo1uu8grRZcqTQB7eXT2CYA+Llg9GcjuRfF2vuDtb8kvRgb89Cownf19thtCHgU FpJdY653Bnpa8Hz0rvBdZkEqMtpYB6Y7TPsfdbnnAwdQ4Q64WHq1jXhlqkDJCqXv7hHg UrdSmAPQyloIxLgcGSLgbO9rnRAhfbU8lYeSeP0e2UWCWAX2b/4nH/ldV+OpQG65lNTL Nn1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=z4iCmcpgVECWJRrqOWd//PjPSZ6hGngwh0fEJcxLSVs=; b=CrfRLUr4yKl8QgPrKnqJ8pMNpwG0mpsUemKaXOGBk7ajR2W2ImDyVeUHrOe4QxZKl7 FbwyPYCH7Fp71MLOlXG6vCZcUgQ5+4XC9z7sIIlYDjiS6k7Z3YaEXm2gEyKMyLkX53wM sNreLo4oW/ur7Mnz1DIc09Q07HUx+p5Ohnu3PvnDG+LW8tjTkgo3m+76R1x7Bfd1dm2B fQxTWaa8KW/IZIeQOk3nuXmbXj0jdEYvloCuWMVaYUNt1jAvNK+Lbz7YNMJwnIoysmOJ 4zjiqwkkS9Hka7PKr0BS/VSu0EJiqvts2omPMDaz1AlsYzq8YH4ClqbvDVVHZqcgc2RQ Ls8Q== X-Gm-Message-State: AOAM532tFieZob7CN9Y42u+geZOGatse5RewjyDq/HJCVkfDjmofWU7V paHc9qCeLZa3DIGu5Ap21RbXWU0V9ze9616tGCM= X-Google-Smtp-Source: ABdhPJxFjHAzBA/r/Nga81TMCwsWTwWW8snspute3WmtA0rRgHwxqJRe+pWKWwkijin05Zam7ekM2ESwCjg1mc4Nyo0= X-Received: by 2002:a92:c566:: with SMTP id b6mr12955147ilj.162.1619430315486; Mon, 26 Apr 2021 02:45:15 -0700 (PDT) MIME-Version: 1.0 References: <2273212.ItJIoklBD0@thomas> In-Reply-To: From: Jerin Jacob Date: Mon, 26 Apr 2021 15:14:59 +0530 Message-ID: To: Honnappa Nagarahalli Cc: Kathleen Capella , "thomas@monjalon.net" , "dev@dpdk.org" , Dharmik Thakkar , Ruifeng Wang , "david.marchand@redhat.com" , Bruce Richardson , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , Ferruh Yigit , "Ananyev, Konstantin" , Stephen Hemminger , nd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" On Sat, Apr 24, 2021 at 5:56 AM 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 hav= e > > > > > > > > > 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 debu= g > > > > > > > > > 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 th= e > > > > > > > > > community would be interested in taking a look. Please le= t > > > > > > > > > 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 i= t > > > > > > > > > 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 every= thing. > > > > > > > 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 an= d > > > > > 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 spe= cific to > > L3fwd application. > > > > I meant creating generic counter-read/write infra via memzone to not ma= ke it > > as l3fwd specific. > Currently, app/proc-info is able to print the stats as they are standardi= zed 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 d= isplaying utility and the application has to do all the heavy lifting of co= pying 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 u= nder > > 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, i= s it correct? For ex: for burst stats, there will be several traces generat= ed collecting the number of packets returned by rte_eth_rx_burst which need= s 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.