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 A6BB1A04DB; Fri, 16 Oct 2020 14:20:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 85E521ED98; Fri, 16 Oct 2020 14:20:46 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by dpdk.org (Postfix) with ESMTP id C983E1ED80 for ; Fri, 16 Oct 2020 14:20:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602850842; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vAL+4gLUGTOGUMsTmVewbmXftHxQCJWefMuqSL/tYVw=; b=Ya6+0aNqXRHTfC/Wx9h0UWs0orKDeIkDRN5DiSZouSmkhwMZryJU+lg38X02Q32nNKU1ZV xs3Dsf7U83blXZpVIws4wOEkcV9r94lQVD2xAnmmcWcv3arDKso/97dbBP8/o8ykVt2Ps9 oGIVu6har1zsuidhlfeGHEvdHJ7WSmc= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-463-pT8doPfZOVCp8tlLghG2zg-1; Fri, 16 Oct 2020 08:20:40 -0400 X-MC-Unique: pT8doPfZOVCp8tlLghG2zg-1 Received: by mail-vk1-f200.google.com with SMTP id e6so855990vkb.11 for ; Fri, 16 Oct 2020 05:20:40 -0700 (PDT) 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=vAL+4gLUGTOGUMsTmVewbmXftHxQCJWefMuqSL/tYVw=; b=J5pVJVrpuUdVGiO0kB2YGOYOwFj2bFB/wqXuxiB80zgzBd7FlNlC+b9F9MWsrl0joG Wf9ae9iMpQ6z/Ci9U1z2lxA6C0vAYG7zj9HCKUkS/0dZYE0Bl2MlEVNwnkkALRBhD/L4 pT+EH4cHTkMjoEWKZA1gRHbaaDMqFhS1VC9I9epRQPzZjY1L4kJlrqM1OGFrOn6J8tEt TjDxZWUQw3A7j1THp95ZRy5GvJ6QGQU1qVXWSYeiNA2wQvjgyMlB/rPmB/wp9fx32Hl2 tbrVSphJ5OAXDn5WMVWdfrTaIEin8Rc/k92dDIqbthjaTa7VPbwPZ6mf0eGj9WhN3LzK YacA== X-Gm-Message-State: AOAM530m6kx5KAvxgobuNBrtN+iMPLxKh+xCgF1f41JrP3Vd4FCRKJm5 XJksfVCRX9T5QKJJcQMgon4kAhBhn/cfqxVDw4sfFhe+rZByaMkZd0Rvdo/mhQNzLz6wTfFoyzF NJNEei4yB3ZEx+/2cufA= X-Received: by 2002:a1f:e905:: with SMTP id g5mr1707274vkh.17.1602850840024; Fri, 16 Oct 2020 05:20:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMLNdLLBnbqbsDexCYitz7EM8Z3W2tCMU2cUNUTYZDE/qpZ7ljRLAS7Wz6pz6g6cdyBLyi411ozeoz64kWQ9I= X-Received: by 2002:a1f:e905:: with SMTP id g5mr1707259vkh.17.1602850839827; Fri, 16 Oct 2020 05:20:39 -0700 (PDT) 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: Fri, 16 Oct 2020 14:20:28 +0200 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" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2 1/2] service: add component useful work attribute 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" On Mon, Oct 5, 2020 at 8:59 PM Van Haaren, Harry wrote: > > -----Original Message----- > > From: dev On Behalf Of Van Haaren, Harry > > Sent: Wednesday, September 23, 2020 3:17 PM > > To: Mattias R=C3=B6nnblom ; dev@dpdk.org > > Cc: david.marchand@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 1/2] service: add component useful wo= rk > > attribute > > > > > -----Original Message----- > > > From: Mattias R=C3=B6nnblom > > > Sent: Wednesday, September 23, 2020 12:40 PM > > > To: Van Haaren, Harry ; dev@dpdk.org > > > Cc: david.marchand@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v2 1/2] service: add component useful = work > > > attribute > > > > Hi Mattias, > > > > Thanks for taking time to review & prompt reply! > > Ping Mattias - any input based on follow up discussion below? > > > > > On 2020-09-14 16:37, Harry van Haaren wrote: > > > > This commit adds a new attribute which allows the service to indica= te > > > > if the previous iteration of work was "useful". Useful work here im= plies > > > > forward progress was made. > > > > > > > Exposing this information via an attribute to the application allow= s > > > > tracking of CPU cycles as being useful or not-useful, and a CPU loa= d > > > > 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 sp= end > > cycles polling, and trying to move packets around its internal queues, = but make > > no forward progress. Measuring cycles spent in the service would not in= dicate > > the correct "busyness" in that case. > > > > In the suggested patchset, each service (e.g Eventdev SW PMD) can updat= e > > a statistic itself, pushing an attribute value into the service-cores l= ayer. > > This method allows each PMD to define "useful work" in its own way. > > > > > We did some prototyping on dynamic load balancing for the service cor= e > > > framework, and then we extended the API is such a way that the servic= e > > > 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 servic= e-core > > itself, but how to show that to the application? It still requires an a= ttribute 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 infrastructur= e 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 c= hange. > > > > Pros of adding an API as this patchset proposes is to push attribute va= lues 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? --=20 David Marchand