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 DB0BBA00C4; Fri, 30 Sep 2022 14:32:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7C27A40684; Fri, 30 Sep 2022 14:32:51 +0200 (CEST) Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by mails.dpdk.org (Postfix) with ESMTP id 7571B4003F for ; Fri, 30 Sep 2022 14:32:50 +0200 (CEST) Received: by mail-qk1-f181.google.com with SMTP id h28so2691847qka.0 for ; Fri, 30 Sep 2022 05:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=rmYeTZ3LCjeUt3JUbCYpTaWfzLjB2Sjurno+amdDzCQ=; b=ZnLB+lz2or76PpuER2+5+rqgQKshwlSyh9R1OwnbNdMiTeh5GLdRp1SrttN9khT5A8 d7FlCE03YwjXuySJFnd3x6sS5vMPVOzpKcuP2KD3LMZsXZBcTKEoFEczmAvVQwDfRL7k SNii0ZmRYJFVwJ0Jw6Eb0IvUBE03N9FWfTyhy8rzgRBQBd7LrHUyXF0O5b/8Kq1W94eo j1a/mOgbww6rZOyUw5g5oZkD61UgPrgbhS8ZXVVOyi4lc12eulCKjgLCP6d195s1TFZ1 gSP7Dgbh9YkdFdtf2yoFinYz3lguhCqYMbyyT3uVB7Ol2qpRfWGJn2ny1WpxmTX3/xAa PNyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=rmYeTZ3LCjeUt3JUbCYpTaWfzLjB2Sjurno+amdDzCQ=; b=JRjSA5UtRzDFzC4wYpca8TiLKZRkTzTFvZNeMBcLRUsvn4dZXdxK5vS9BAuSMPEL56 CO04YSbId3QFkv3ik6agdKFepCCbZOx34FByQxU/NrIqXI/HPLQrL4ZFOcSQURhGpnfT gc8+qcGU2B+FCJnflZjZaWg/ki+wA7St9J1QwTqlV8YwoDC58WtViW+NxlpYJ1jXDZ5H 2NLvTontygk9oWU/hah+HdlhBGXy6NZKapJKNA0YuPY47SXndyYteu5873ls1pZFek+e eZV182yGZef8mimm0um4L5IZz/WsoNqir3tbBlb9jmfiU3eFzi7JUFqJ53EB3G2N01jR oS4A== X-Gm-Message-State: ACrzQf34dNnWiNVZVviuSxpxWmKNGfMUMzwrJbhtDWQ7Wek5LfC3gHcO oEo7LB9xvW3PKvBOFAWavlK7B44Fl/UZpnyBYnA= X-Google-Smtp-Source: AMsMyM4hs0RRcAP/JRn5oT0FLG/lOldEho2cyLWqRBjwOcrvDIt9TSdIoCyb6m6UpSD21TWDMETaW47/Ml8zWS5rym4= X-Received: by 2002:a05:620a:198a:b0:6ce:7f32:9f3f with SMTP id bm10-20020a05620a198a00b006ce7f329f3fmr5914130qkb.90.1664541169624; Fri, 30 Sep 2022 05:32:49 -0700 (PDT) MIME-Version: 1.0 References: <24c49429394294cfbf0d9c506b205029bac77c8b.1657890378.git.anatoly.burakov@intel.com> <20220914092929.1159773-1-kevin.laatz@intel.com> <20220914092929.1159773-2-kevin.laatz@intel.com> <9a6fec15f9684d21bb4730596cceacff@huawei.com> <4af4b5d6-57a9-39a4-2197-a2acdc57156b@intel.com> In-Reply-To: From: Jerin Jacob Date: Fri, 30 Sep 2022 18:02:23 +0530 Message-ID: Subject: Re: [PATCH v7 1/4] eal: add lcore poll busyness telemetry To: Kevin Laatz Cc: Konstantin Ananyev , "dev@dpdk.org" , "anatoly.burakov@intel.com" , Conor Walsh , David Hunt , Bruce Richardson , Nicolas Chautru , Fan Zhang , Ashish Gupta , Akhil Goyal , Fengchengwen , Ray Kinsella , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Jerin Jacob , Sachin Saxena , Hemant Agrawal , Ori Kam , Honnappa Nagarahalli , Konstantin Ananyev Content-Type: text/plain; charset="UTF-8" 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 On Thu, Sep 29, 2022 at 6:11 PM Kevin Laatz wrote: > > > > >> 2. Ring does not have callback support, meaning pipelined applications > >> could not report lcore poll busyness telemetry with this approach. > > That's another big concern that I have: > > Why you consider that all rings will be used for a pipilines between threads and should > > always be accounted by your stats? > > They could be used for dozens different purposes. > > What if that ring is used for mempool, and ring_dequeue() just means we try to allocate > > an object from the pool? In such case, why failing to allocate an object should mean > > start of new 'idle cycle'? > > Another approach could be taken here if the mempool interactions are of concern. Another method to solve the problem will be leveraging an existing trace framework and leverage existing fastpath tracepoints. Where existing lcore poll busyness could be monitored by another application by looking at the timestamp where traces are emitted. This also gives flexibility to add customer or application specific tracepoint as needed. Also control enable/disable aspects of trace points. l2reflect is a similar problem to see latency. The use case like above(other application need to observe the code flow of an DPDK application) and analyse, can be implemented as Similar suggesiton provied for l2reflect at https://mails.dpdk.org/archives/dev/2022-September/250583.html I would suggest to take this path to accommodate more use case in future like - finding CPU idle time -latency for crypto/dmadev/eventdev enqueue to dequeue -histogram of occupancy for different queues etc This would translate to 1)Adding app/proc-info style app to pull the live trace from primary process 2)Add plugin framework to operate on live trace 3)Add a plugin for this specific use case 4)If needed, a communication from secondary to primary to take action based on live analysis like in this case if stop the primary when latency exceeds certain limit On the plus side, If we move all analysis and presentation to new generic application, your packet forwarding logic can simply move as new fwd_engine in testpmd(see app/test-pmd/noisy_vnf.c as a example for fwdengine) Ideally "eal: add lcore poll busyness telemetry"[1] could converge to this model. [1] https://patches.dpdk.org/project/dpdk/patch/20220914092929.1159773-2-kevin.laatz@intel.com/ > > From our understanding, mempool operations use the "_bulk" APIs, whereas polling operations use the "_burst" APIs. Would only timestamping on the "_burst" APIs be better here? That way the mempool interactions won't be counted towards the busyness. > > Including support for pipelined applications using rings is key for a number of usecases, this was highlighted as part of the customer feedback when we shared the design. > > > > >> Eventdev is another driver which would be completely missed with this > >> approach. > > Ok, I see two ways here: > > - implement CB support for eventdev. > > -meanwhile clearly document that this stats are not supported for eventdev scenarios (yet).