From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 2EC04A04B5;
	Mon, 11 Jan 2021 09:44:29 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id E5D5E140CBB;
	Mon, 11 Jan 2021 09:44:28 +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 C9205140CB8
 for <dev@dpdk.org>; Mon, 11 Jan 2021 09:44:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1610354666;
 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=Mbi00mGAwHoNWzfPkQkb+G97KyY0yDYeVuzmW5Ft0Rs=;
 b=UxupPzI2rbgwuYIvDYyDpwHzOwU9S37uZZJgnJbEXAJh4Cj/G6REJ7vW77YwOntBdXvr84
 4R6lhxgNxx8bxg+K19WoC9bjsTC0Mny+Arb34XEx8gDFB5wIBIUO9MpOBZ6kc1jujOqoMy
 HggrJ+PW/OAz5Wj02Ifq2h1GvX5jE/A=
Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com
 [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-338-Td3rUtmvPh2R5PTVv5UjLw-1; Mon, 11 Jan 2021 03:44:22 -0500
X-MC-Unique: Td3rUtmvPh2R5PTVv5UjLw-1
Received: by mail-vs1-f72.google.com with SMTP id y12so4309461vsq.21
 for <dev@dpdk.org>; Mon, 11 Jan 2021 00:44:22 -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=Mbi00mGAwHoNWzfPkQkb+G97KyY0yDYeVuzmW5Ft0Rs=;
 b=WqbV4Zknad7vonwnnaNclLQaMFDh7Y7wlGowaCwKpjUW7/TZ6/nRgnb5sJRU+e/ZPw
 kAPPh7HqaTBJMIud7z565jgv9hT9AMw9oeGwheBJv444aFneTzGWWYNMYrTf93PvGXvQ
 Zk+RCYKlWJa5y2fGa4jyMKdYa5yDVYFPBq/z4v+cY/DXbH4EgjbEztlkDu+XAdhcvXS2
 MWqbz6XGqGa33/nXh4Vle+h/YR5UNMlHs2AAkzWfaC4OXjogp/LS9UH7ULdNqXv2tLI+
 zGoohTdyzLvuI7Y4OnKd4Y4/oH/F+IgSLPiz4P9VB5Be3qqmGxJimPXwhTEWRimn70tm
 ApLw==
X-Gm-Message-State: AOAM531Sb7jCoUccOkPnsBVH783E705cTNEW3lb0Vq+Ahx7fmTRW17RQ
 7TlyONBkrdmz+psnaR1HhMwZ7bpa3TCczALRmpN2GglWCaKn4acHSPRAZ9KoxDBrxASATO9qy6N
 HmRkKH4ODpbkR9MZlRfU=
X-Received: by 2002:a1f:cec1:: with SMTP id e184mr12050934vkg.17.1610354662104; 
 Mon, 11 Jan 2021 00:44:22 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyXHu7ZSIxHigqk0mTPqUtzjD6/pJFATHqvWlLh0TG+aixus4jlyqCZRbm3OpdCCRBnicIuaqCbyhgvCFTkdMM=
X-Received: by 2002:a1f:cec1:: with SMTP id e184mr12050923vkg.17.1610354661901; 
 Mon, 11 Jan 2021 00:44:21 -0800 (PST)
MIME-Version: 1.0
References: <1604315406-27669-1-git-send-email-liang.j.ma@intel.com>
 <cover.1608213657.git.anatoly.burakov@intel.com>
 <CAJFAV8w_0mpmVKZZKSGMFvFbFZ1KUZECGUXesRGnokNFJYRT2g@mail.gmail.com>
 <d7272849-606d-590a-c3c3-1d5546b1279f@intel.com>
In-Reply-To: <d7272849-606d-590a-c3c3-1d5546b1279f@intel.com>
From: David Marchand <david.marchand@redhat.com>
Date: Mon, 11 Jan 2021 09:44:10 +0100
Message-ID: <CAJFAV8xM0Fjd7CB1KNT1Wi8vn0Qx2u6CkjrPZ6qDkxd_wntfEQ@mail.gmail.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>, 
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Gage Eads <gage.eads@intel.com>, 
 Timothy McDaniel <timothy.mcdaniel@intel.com>,
 David Hunt <david.hunt@intel.com>, 
 Bruce Richardson <bruce.richardson@intel.com>, chris.macnamara@intel.com, 
 Ray Kinsella <mdr@ashroe.eu>, "Yigit, Ferruh" <ferruh.yigit@intel.com>
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 v12 00/11] Add PMD power management
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Jan 8, 2021 at 5:42 PM Burakov, Anatoly
<anatoly.burakov@intel.com> wrote:
>
> On 17-Dec-20 4:12 PM, David Marchand wrote:
> > On Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov
> > <anatoly.burakov@intel.com> wrote:
> >>
> >> This patchset proposes a simple API for Ethernet drivers to cause the
> >> CPU to enter a power-optimized state while waiting for packets to
> >> arrive. This is achieved through cooperation with the NIC driver that
> >> will allow us to know address of wake up event, and wait for writes on
> >> it.
> >>
> >> On IA, this is achieved through using UMONITOR/UMWAIT instructions. They
> >> are used in their raw opcode form because there is no widespread
> >> compiler support for them yet. Still, the API is made generic enough to
> >> hopefully support other architectures, if they happen to implement
> >> similar instructions.
> >>
> >> To achieve power savings, there is a very simple mechanism used: we're
> >> counting empty polls, and if a certain threshold is reached, we get the
> >> address of next RX ring descriptor from the NIC driver, arm the
> >> monitoring hardware, and enter a power-optimized state. We will then
> >> wake up when either a timeout happens, or a write happens (or generally
> >> whenever CPU feels like waking up - this is platform-specific), and
> >> proceed as normal. The empty poll counter is reset whenever we actually
> >> get packets, so we only go to sleep when we know nothing is going on.
> >> The mechanism is generic which can be used for any write back
> >> descriptor.
> >>
> >> This patchset also introduces a few changes into existing power
> >> management-related intrinsics, namely to provide a native way of waking
> >> up a sleeping core without application being responsible for it, as well
> >> as general robustness improvements. There's quite a bit of locking going
> >> on, but these locks are per-thread and very little (if any) contention
> >> is expected, so the performance impact shouldn't be that bad (and in any
> >> case the locking happens when we're about to sleep anyway, not on a
> >> hotpath).
> >>
> >> Why are we putting it into ethdev as opposed to leaving this up to the
> >> application? Our customers specifically requested a way to do it wit
> >> minimal changes to the application code. The current approach allows to
> >> just flip a switch and automatically have power savings.
> >>
> >> - Only 1:1 core to queue mapping is supported, meaning that each lcore
> >>    must at most handle RX on a single queue
> >> - Support 3 type policies. Monitor/Pause/Frequency Scaling
> >> - Power management is enabled per-queue
> >> - The API doesn't extend to other device types
> >
> > Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this:
> > https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082
> >
> > We will have to put an exception on driver only ABI.
> >
> >
>
> Why does aarch64 build fail there? The functions in question are in the
> version map file, but the build complains that they aren't.

>From what I can see, this series puts rte_power_* symbols in a .h.
So it will be seen as symbols exported by any library including such a header.

The check then complains about this as it sees exported symbols
unknown of the library version.map.


-- 
David Marchand