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 C6DE7A04B5; Wed, 13 Jan 2021 15:43:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37382140D93; Wed, 13 Jan 2021 15:43:02 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id AEAAC140D73 for ; Wed, 13 Jan 2021 15:43:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610548980; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=k31qFYHAL05EdGqyLUOKKcoVJsg2zdjdmtSx6TpZVro=; b=iJHpzGIPeQI7KXLzJ2F1ixC14myAJCWCwVE5J86fweyjSmEjQGH2C8D4SsPxZ54xFGYe0n WhvpvkWLOJgkpchzb3nHS5qO2GYjBy3wzC0wstTM9X2blrmTiRGF9R8wt4QpDNsYkpzbst FmMmpH2KuElP21F2IF6X8EARPuJ1bkA= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-404-SAtq8Lu_Oo2I7QkFKOPRrQ-1; Wed, 13 Jan 2021 09:42:58 -0500 X-MC-Unique: SAtq8Lu_Oo2I7QkFKOPRrQ-1 Received: by mail-vs1-f69.google.com with SMTP id a11so313345vsr.2 for ; Wed, 13 Jan 2021 06:42:58 -0800 (PST) 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=k31qFYHAL05EdGqyLUOKKcoVJsg2zdjdmtSx6TpZVro=; b=LWHTeV9u9rFp2ChnaCas0M1a0G7xapFxwmBaAGLQAtQAn65AW/cG/cE5Hggye9ZVw5 9mzQMw569Oh8T3Dnemrzu9SXp0EA8Y80OQMXBhx5jbFMfLb7zxQVKax1DK02oDWybEo2 6HLIcrnhxPWQCsAEJy5KfdhYIBShHXiOpnPONDkYIJRBIeyLW388sNZlCyQgMHd1Qq7S xFnAs6/5FWZFoonotAMc7QZoDaDDmiWFEFEevOCACkLRp1LE+Xq5gKWQ5fB2/+6jQJY4 oY4i9ubTt2xb/Sz/h5pav8ZVfhMcMU47Twczs6Ub5mnPJKb4w9c9gJDFPPM0OHnA1iQb PkGA== X-Gm-Message-State: AOAM532T0P2JdCsr8dfM5Kzxcy3k8a07fvtyxNnEJFAttpzOsoZ8ltnC EU1A1jyz6MW3gdBNmeREF4fId0c+CokG3XHGLDTpWvAHWi85smHozDivOJPKk8H1Er9b6NyWKWp Io/UAyQ/VFGYaIDcC+w8= X-Received: by 2002:a05:6102:21cd:: with SMTP id r13mr2303072vsg.5.1610548978052; Wed, 13 Jan 2021 06:42:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJwxdgEqgcB0oNB10Wfc9TtuOEnmfL1y357MF1nWKYy8t+P1thYF4gv46T73Sdz+k8fsUK4R36Qzw1LXHGorRfo= X-Received: by 2002:a05:6102:21cd:: with SMTP id r13mr2303043vsg.5.1610548977825; Wed, 13 Jan 2021 06:42:57 -0800 (PST) MIME-Version: 1.0 References: <20200907162149.31454-1-harry.van.haaren@intel.com> <20200914143732.87907-1-harry.van.haaren@intel.com> <3213ba3a-e0b0-9a05-1cdb-4da5abc001b4@ericsson.com> In-Reply-To: From: David Marchand Date: Wed, 13 Jan 2021 15:42:46 +0100 Message-ID: To: "Van Haaren, Harry" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: "dev@dpdk.org" Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 1/2] service: add component useful work attribute 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" Hello Harry, Mattias, On Fri, Oct 16, 2020 at 2:57 PM Van Haaren, Harry wrote: > > > > > On 2020-09-14 16:37, Harry van Haaren wrote: > > > > > > This commit adds a new attribute which allows the service to indicate > > > > > > if the previous iteration of work was "useful". Useful work here implies > > > > > > forward progress was made. > > > > > > > > > > > Exposing this information via an attribute to the application allows > > > > > > tracking of CPU cycles as being useful or not-useful, and a CPU load > > > > > > estimate can be deduced from that information. > > > > > > > > > > > > > > > How would that tracking be implemented? rte_service.c already keeps > > > > > track of the amount of busy cycles per service. Would it be possible to > > > > > reuse that mechanism to achieve the same goal? > > > > > > > > Tracking "busy cycles" is not exactly the same - Eventdev SW PMD can spend > > > > cycles polling, and trying to move packets around its internal queues, but > > make > > > > no forward progress. Measuring cycles spent in the service would not indicate > > > > the correct "busyness" in that case. > > > > > > > > In the suggested patchset, each service (e.g Eventdev SW PMD) can update > > > > a statistic itself, pushing an attribute value into the service-cores layer. > > > > This method allows each PMD to define "useful work" in its own way. > > > > > > > > > We did some prototyping on dynamic load balancing for the service core > > > > > framework, and then we extended the API is such a way that the service > > > > > callback would return a bool indicating if forward progress was made, if > > > > > I recall correctly. Sampling these counters allowed for tracking load on > > > > > both a per-lcore and per-service basis. > > > > > > > > The service callback return value can be stored/inspected on the service-core > > > > itself, but how to show that to the application? It still requires an attribute API > > > > like proposed below re-using "attr_get" API I think. > > > > > > > > So really the only difference in the prototype you mention is how the > > > > service itself communicates business to the service-cores infrastructure in > > EAL. > > > > > > > > Perhaps re-purposing return-value is simpler, but it limits statistics from the > > > > service to just business, and the API change requires all services to change. > > > > > > > > Pros of adding an API as this patchset proposes is to push attribute values to > > > > service-core in EAL is extensibility, and no API breakage. > > > > > > > > Given that context, Ack / push-back to this suggested approach? > > > > I need a conclusion. > > Is this required for 20.11? > > Given timeline - lets leave this until 21.02 release. > I think the above solution is adequate, but don't want to rush folks. > > Thanks for following up, chat next release. -Harry > Did some discussion happen? 21.02-rc1 is coming soon. -- David Marchand