From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id F0518A0679 for ; Tue, 30 Apr 2019 22:53:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EFACE493D; Tue, 30 Apr 2019 22:53:27 +0200 (CEST) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 0476629CB for ; Tue, 30 Apr 2019 22:53:26 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id w25so7641992pfi.9 for ; Tue, 30 Apr 2019 13:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=xd/7fF5bo8sJ4wESv7oaM2v5i6/Vxf1t9a0w/OSzNwI=; b=PGwRTd3wOlpTAkLQPB4VJ7borqwxvEyCmtXyOVSD4tj9/3p8syogXaYfI+3cnDGcpk wlAu/7W1P0j5jfIFbcHK7XxZLUcXvM1CLgoKIvNEXpB7LIaOGN7Jye4iEwslKMulbie4 GrmHy4Q1lXIvlIUZzPBDGWdbtS9blBV/bSrCmJ7c0KyMVT0+7tLlOnYYLiuZJUbdSnB5 UtFQcZBVygTG5+mRddl3Z73eIjIL+GqbgqSBBLbJaC1pP1j/OpOgQMcZQGHGMKKWtQei eD0eg0KU3hS/a/ATFXSGWcgvBiOksTr2hmy3vNXxKfZSNQa1OXyN9dGdfofmezYvNKu3 p3Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=xd/7fF5bo8sJ4wESv7oaM2v5i6/Vxf1t9a0w/OSzNwI=; b=GIvLQMu9FDjxJxjg8ge/J+5U55a4yJfyjOQlLMhlAYVIdcEfIZ7J2zw6DQXmHwC6SI TX8LpD75NrpbrcrZLCCRTXpK7iDTZH26byrcedtwZHyDr3BqRqrfa/2Z7axltHr+UyCD eQc2dlhhQedlw6+rYGSffOazvoNtUYx6wvbMEGe3Q00Z+gkGfYv+5/n4UTIAm6NLKINh kfIepnFFV05Y300jb4iJJ6dPnjq+b0c87Y1aVc4Nu6ptRhKTCmc1+DLNXlLHhSy2ponh ZkMS/thdolpvJkXEkfD9rILeOhW2nPkh3ZK1jRx8QBXNzU1dy6Z6cD82mvNFGV5fcyaq O5+g== X-Gm-Message-State: APjAAAU6HtdtJq+cWA09LXu61v+UMYlDfcc4x357dOAvaRMPL9kVtdDt RTn0BUoUUIMeYrXKUe0qZfdFAw== X-Google-Smtp-Source: APXvYqxOnAZ1OXFvbdwrKyDnheluWcQvYg+H2PWfBsVkBP/+Cp+3Wvmkpu4gA5NaqSFq8aMAhaMEqg== X-Received: by 2002:a62:1881:: with SMTP id 123mr73013443pfy.25.1556657605173; Tue, 30 Apr 2019 13:53:25 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id v12sm12591845pfm.186.2019.04.30.13.53.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Apr 2019 13:53:25 -0700 (PDT) Date: Tue, 30 Apr 2019 13:53:15 -0700 From: Stephen Hemminger To: Jerin Jacob Kollanukkaran Cc: "dev@dpdk.org" Message-ID: <20190430135315.037f06c4@hermes.lan> In-Reply-To: References: <20190408182510.16078-1-stephen@networkplumber.org> <20190410171603.8979-1-stephen@networkplumber.org> <20190410171603.8979-3-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config 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" Message-ID: <20190430205315.jG2evJJ8GC4B6LpZQoUMAWiFo_k90Say7myyBQeQye8@z> On Tue, 16 Apr 2019 17:03:47 +0000 Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: dev On Behalf Of Stephen Hemminger > > Sent: Wednesday, April 10, 2019 10:46 PM > > To: dev@dpdk.org > > Cc: Stephen Hemminger > > Subject: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config > > > > The fields of the internal EAL core configuration are currently laid bare as part of > > the API. This is not good practice and limits fixing issues with layout and sizes. > > > > Make new accessor functions for the fields used by current drivers and > > examples. Mark return code functions as experimental since this value might > > change in the future and probably shouldn't have been used by non EAL code > > anyway. > > > > Signed-off-by: Stephen Hemminger > > Reviewed-by: David Marchand > > Shared Library Versions > > ----------------------- > > diff --git a/lib/librte_eal/common/eal_common_lcore.c > > b/lib/librte_eal/common/eal_common_lcore.c > > index 1cbac42286ba..6cf4d7abb0bd 100644 > > --- a/lib/librte_eal/common/eal_common_lcore.c > > +++ b/lib/librte_eal/common/eal_common_lcore.c > > @@ -16,6 +16,45 @@ > > #include "eal_private.h" > > #include "eal_thread.h" > > > > +int rte_lcore_index(int lcore_id) > > +{ > > + if (unlikely(lcore_id >= RTE_MAX_LCORE)) > > + return -1; > > + > > + if (lcore_id < 0) > > + lcore_id = (int)rte_lcore_id(); > > + > > + return lcore_config[lcore_id].core_index; > > +} > > If I understand it correctly, We are planning to do this scheme only for slow path functions. Right? > Is rte_lcore_* functions comes in slow path category? I thought a few of them can be used > In fast path too. > I am bit concerned about a low end arm cores where function invocation overhead significant vs inline. > ODP has taken a route of introducing a compile time config to choose inline vs separate function to address > the performance regression . I am not sure what would be the correct way to handle this. The lcore config itself is not accessed anywhere in fastpath of any of the examples. It is usually is part of the setup process. The rte_lcore_index is only used by lthread in a log message. The main fastpath is rte_lcore_id() which is already done by per-thread variable and is unchanged by these patches. I don't have facilities to do any deep dive performance testing on ARM.