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 5437AA09F6; Thu, 17 Dec 2020 17:12:57 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2E8ACA2C; Thu, 17 Dec 2020 17:12:55 +0100 (CET) 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 BE7A1CA2A for ; Thu, 17 Dec 2020 17:12:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608221572; 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=AQI3guFiKaTj+oIIVuCpULpcPbcWIALXTWWHiUlOsK0=; b=ibMkqMZgQx3LRY3OnJLCOoQd0tlhZYziSldSG483A0aX5Vqvu2YIdrpRFmhsLuBBn3To31 G5yWnzIeftfzaQWmJV9Q1ueaCvFDSRvJNnVXMACXJt8QCVQRxhP/SsP5lebqYuOFRy+Cl4 qB4Rd1E+QjrmlJteVbnwiaDv5jedgVo= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-97Bx5UItMbWIRiDWosROhQ-1; Thu, 17 Dec 2020 11:12:49 -0500 X-MC-Unique: 97Bx5UItMbWIRiDWosROhQ-1 Received: by mail-vk1-f197.google.com with SMTP id r62so12233771vkr.22 for ; Thu, 17 Dec 2020 08:12:48 -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=AQI3guFiKaTj+oIIVuCpULpcPbcWIALXTWWHiUlOsK0=; b=KnaFe0X8/MfhY7KGkRB2nGfMTXZts5AUQjVnRLHHp07fIRPMbk8OYsnwMw4xV/c6kc dWKjLq/ks31ISPuadUjlHls0w/U02UD8GBTKaztSwh34O1dOLj8ZEQkGg4wAVNls3CJt 24+BRrv2R7VWJT2XxCDwWZQ0hTB3bruO8DjMPd3IccAUVZONJodgOQfFn5rc0pjua0ln m9bgcfOimEFWddEZDZ9tuggr4JkgU9Jw3TOZBEQsVKjLBOvaKfFT5eGXKqef56PlQnyY DTIt5G4+4eaY6+ASbsjD4fwJYrrCpVC2oeD/frVuRvVn0JDM9m68tKEp6B6x7RYWNtBv 8NxQ== X-Gm-Message-State: AOAM530R9ODmooKUWDcfVGHEA93laOLM5EI+z0pEQD6oOU4mp9CKxqwv ONTuSzh4i5LfwWb/qf4i80Hok4msa1pQODd8Doq0NxxHOZ5w8CFa5jD/fgvax23hp6oq7hN2D1i NeVLygjgjSHJu1qW2TPo= X-Received: by 2002:a1f:96cd:: with SMTP id y196mr96696vkd.18.1608221568479; Thu, 17 Dec 2020 08:12:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+RWtBGsOr5MvLmUzwCJg4gmKawfA0Q3LcJHvsSjN7kpDTyayymZGwKQxVz0x8IyG91KQOjhIRONOR8lP7a4k= X-Received: by 2002:a1f:96cd:: with SMTP id y196mr96643vkd.18.1608221568138; Thu, 17 Dec 2020 08:12:48 -0800 (PST) MIME-Version: 1.0 References: <1604315406-27669-1-git-send-email-liang.j.ma@intel.com> In-Reply-To: From: David Marchand Date: Thu, 17 Dec 2020 17:12:36 +0100 Message-ID: To: Anatoly Burakov Cc: dev , Thomas Monjalon , "Ananyev, Konstantin" , Gage Eads , Timothy McDaniel , David Hunt , Bruce Richardson , chris.macnamara@intel.com, Ray Kinsella , "Yigit, Ferruh" 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.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 Thu, Dec 17, 2020 at 3:06 PM Anatoly Burakov 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. -- David Marchand