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 4874CA0527; Sun, 29 Nov 2020 15:43:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9AF8DC8C6; Sun, 29 Nov 2020 15:43:35 +0100 (CET) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by dpdk.org (Postfix) with ESMTP id 8B24DC86E for ; Sun, 29 Nov 2020 15:43:33 +0100 (CET) Received: by mail-lf1-f44.google.com with SMTP id l11so15483421lfg.0 for ; Sun, 29 Nov 2020 06:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weka.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z7vVg1w/SXxiGdrDVgo1tC0GnUFR4pFpyT7a+twFEpQ=; b=Q1UVAfRqZe0fTIDr8XfoDefnr/cIBBgHr0UFNieIIUOeL7c9ekHU0eKSZkeysm0TmU uTuPw+iQ0I5AQZoGbMYJs66JcY5iMJ4GdkGfRZt+3/VQhh1fNoAUZp7KH6SXai4dQqYz 81zRbLgEZ5PwIlTJxTrvVffJmyv63bYQ7JHXA= 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; bh=Z7vVg1w/SXxiGdrDVgo1tC0GnUFR4pFpyT7a+twFEpQ=; b=AtSZRJSj9xa/UcZW69a0qebwf2ahlvZ8fR++zXI1M8KopAAWHJ2Jbwrg1ap5HW9rWZ 7uEoKZ8sJwe5FuUtdmpIZ1sU2ZJxy+lMNj7KmFEcPUsl5QhtmHP2DUWq3CdKsjm8OoG9 jEWfN0NyygPfD+A5ga26Fyt0+HaO9BIZ4rXtIdVC540ooEpK/zTBfQKW2p/l8REDdJzk OL+jsE1QF2SO2LMGC/WHDGINGCh7Z1b/fsWDa2CFDA4m2kjWnu8ilXT9g6jTyMVfmYWF WZnFvfoE7jrnIJgVRDr0PgJqDOQoyLIFKxKSbKRfWPBLKoBOttGXw71RNThkCeHc7sqP 7E9g== X-Gm-Message-State: AOAM531+gEk1MV+Srm4W94wzvyThPuhhGZHmt1pVd/qSOtfX2vr+G/U6 VIoZKKIKnPS06PyBsfWv/RZfW3ArfB8KSokIbu1P2Mb7A7yxBt6ikB+ln50fjEN2v1X+Zs+0Wkn pLDbG8AUznWpgO4p6pmL34e1+UKRLaA6d6WwtQ3mlk+pccERVAOM/cB72p77D3I2VhKS7PFLU+M 2qzA== X-Google-Smtp-Source: ABdhPJyZUsMLAtlyPI/2Yrs81JzcslSLZiLWx6s4vJwy71z5C4q2NX7g4BoHc3Zh9KO9ZY0hsonfigxNfzZOPQvt0sE= X-Received: by 2002:ac2:52a7:: with SMTP id r7mr6230405lfm.264.1606661011968; Sun, 29 Nov 2020 06:43:31 -0800 (PST) MIME-Version: 1.0 References: <20201125143930.C6ED.17218CA3@ntt-tx.co.jp_1> <98CBD80474FA8B44BF855DF32C47DC35C6144E@smartserver.smartshare.dk> <20201126102049.C6F8.17218CA3@ntt-tx.co.jp_1> In-Reply-To: <20201126102049.C6F8.17218CA3@ntt-tx.co.jp_1> From: Baruch Even Date: Sun, 29 Nov 2020 16:43:20 +0200 Message-ID: To: Hideyuki Yamashita Cc: Morten Brorup , dpdk-dev X-CLOUD-SEC-AV-Sent: true X-CLOUD-SEC-AV-Info: weka,google_mail,monitor X-Gm-Spam: 0 X-Gm-Phishy: 0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] NTT TechnoCross roadmap for 21.02 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" Hi, The way we do this accounting is completely different, it depends on having logic that says you are in idle state and counts the start and stop time from entering to exiting the idle function. It then subtracts the idle time from the stat period time and that gives you the time (also percentage) that you spend idle polling. The idle loop at the most basic form only does the polling and excludes time when there were packets received (or other things your app does not connected to DPDK on the same core). Using the counters for the number of polls is going to be harder to use and far less effective. Baruch On Thu, Nov 26, 2020 at 3:21 AM Hideyuki Yamashita < yamashita.hideyuki@ntt-tx.co.jp> wrote: > Hello Morten, > > Thanks for your giving me your valuable feedback. > Please see inline tagged with [Hideyuki]. > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Hideyuki > Yamashita > > > Sent: Wednesday, November 25, 2020 6:40 AM > > > > > > Hello, > > > > > > Following are the work items planned for 21.02 from NTT TechnoCross: > > > I will try to post patch set after 20.11 is released. > > > > > > --- > > > 1) Introduce API stats function > > > In general, DPDK application consumes CPU usage because it polls > > > incoming packets using rx_burst API in infinite loop. > > > This makes difficult to estimate how much CPU usage is really > > > used to send/receive packets by the DPDK application. > > > > > > For example, even if no incoming packets arriving, CPU usage > > > looks nearly 100% when observed by top command. > > > > > > It is beneficial if developers can observe real CPU usage of the > > > DPDK application. > > > Such information can be exported to monitoring application like > > > prometheus/graphana and shows CPU usage graphically. > > > > This would be very beneficial. > > > > Unfortunately, this seems to be not so simple for applications like the > SmartShare StraightShaper, which is not a simple packet forwarding > application, but has multiple pipeline stages. Our application also keeps > some packets in queues for shaping purposes, so the number of packets > transmitted does not match the number of packets received within some tim= e > interval. > > [Hideyuki] > Thanks. > I share the same view with you. > DPDK application varies and not all applications "simply forward > incoming packets". > So I think maybe target applications are limited. > Though I believe this enhancement is useful for those applications still. > > > > > > > To achieve above, this patch set provides apistats functionality. > > > apistats provides the followiing two counters for each lcore. > > > - rx_burst_counts[RTE_MAX_LCORE] > > > - tx_burst_counts[RTE_MAX_LCORE] > > > Those accumulates rx_burst/tx_burst counts since the application > > > starts. > > > > > > By using those values, developers can roughly estimate CPU usage. > > > Let us assume a DPDK application is simply forwarding packets. > > > It calls tx_burst only if it receive packets. > > > If rx_burst_counts=3D1000 and tx_burst_count=3D1000 during certain > > > period of time, one can assume CPU usage is 100%. > > > If rx_burst_counts=3D1000 and tx_burst_count=3D100 during certain > > > period of time, one can assume CPU usage is 10%. > > > Here we assumes that tx_burst_count equals counts which rx_burst > > > function > > > really receives incoming packets. > > > > I am not sure I understand what is being counted in these counters. The > number of packets in the bursts, or the number of invocations of the > rx_burst/tx_burst functions. > [Hideyuki] > Latter. > I think exsisting mechanism may store number of packets. > (maybe I am wrong) > > > > > Here are some data from our purpose built profiler, illustrating how > nonlinear this really is. These data are from a SmartShare appliance in > live production at an ISP. I hope you find it useful: > > > > Rx_burst uses ca. 40 CPU cycles if there are no packets, ca. 260 cycles > if there is one packet, and down to ca. 40 cycles per packet for a burst = of > many packets. > > > > Tx_burst uses ca. 350 cycles for one packet, and down to ca. 20 cycles > per packet for a burst of many packets. > [Hideyuki] > Thanks for your sharing useful info! > Ah, I realized that consumption of CPU cycle is not linear like > following. > > 0 packet receive -> 0 cycle > 1 packet receive -> 1 cycle > 10 packets receive -> 10 cycle > > It is very interesting. > Thanks for your information. > I will keep your information in my mind. > > > One of our intermediate pipeline stages (which not is not receiving or > transmitting packets, only processing them) uses ca. 150 cycles for a bur= st > of one packet, and down to ca. 110 cycles for a burst of many packets. > > > > > Nevertheless, your suggested API might be usable by simple > ingress->routing->egress applications. So don=E2=80=99t let me discourage= you! > [Hideyuki] > Thanks for your supporting my idea. > Yes, I agree with you that for simple forwarding applications, > this enhancement might be useful to monitor the cpu usage "roughly". > > BR, > Hideyuki Yamashita > NTT TechnoCross > > > > > > --=20 Baruch Even Platform Team Manager at WekaIO +972-54-2577223 *=E2=80=A2* baruch@weka.io *=E2=80=A2* https://www.weka.io/ The World's Fastest File System