From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by dpdk.org (Postfix) with ESMTP id D934D5592 for ; Tue, 9 Apr 2019 09:43:11 +0200 (CEST) Received: by mail-ua1-f43.google.com with SMTP id t15so524487uao.5 for ; Tue, 09 Apr 2019 00:43:11 -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; bh=ie/HijC8McJivm10IRTTTWhPRe5yCknyQZSfgPf1Jz8=; b=UVcb1c9VCEZrkk6tCUWx5n3Ln9tAXe99Nhe8GSLzX1Gp8f4pg8dU8zjdazS/5J8Zxg ds2ogF3fSbUAFrd4e/KSHj2PxzmbXwG35JuNacXSA1tfErNarF6b4O0ptxL6dnWvo5ZI ZNoIa+OvERhKgMBhPJAmNXNY21nW9hBjvZwLKu00QnbCkWoflEvqhObc5/SHNy5lOuEV 4V0jvYY0h85I9cZU59dwKO6J5Bh32MUEcxfPxnGvrflspdbWk7V66Wn7aV4OErSsb3Qf BmyFKbVphd6zWAFtlU8ZmH6ZlBJjZ8uZik+G0DUmVqN5BV3H3ohyd3zsVgRBm736k9P2 wBqA== X-Gm-Message-State: APjAAAUjp20tOYE6ZEChmmhX8/q6BGE+xIGrGbzJWa/iynW6jLcGD/gl jnaDW1pvp08crcb/QB9G9CG0qz/N4j+lsuzmfVbkErUt X-Google-Smtp-Source: APXvYqx6JTaZbLD3ZHlbDWvUKLW8PRh+l7kW6TI78lheZwJY+1RsySkN8vWT9O11PieldISfzbstefTIwIeUgs7sU5s= X-Received: by 2002:ab0:b05:: with SMTP id b5mr9827557uak.73.1554795791258; Tue, 09 Apr 2019 00:43:11 -0700 (PDT) MIME-Version: 1.0 References: <20190408182510.16078-1-stephen@networkplumber.org> <20190408182510.16078-2-stephen@networkplumber.org> In-Reply-To: <20190408182510.16078-2-stephen@networkplumber.org> From: David Marchand Date: Tue, 9 Apr 2019 09:43:00 +0200 Message-ID: To: Stephen Hemminger Cc: dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 1/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: , X-List-Received-Date: Tue, 09 Apr 2019 07:43:12 -0000 On Mon, Apr 8, 2019 at 8:25 PM Stephen Hemminger wrote: > 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 the state and return code functions as experimental > since these values might change in the future and probably shouldn't > have been used by non EAL code anyway. > You removed the state function, no need to mention it. Since we already expose the state, exposing the ret code seems fair. Applications can wait themselves and check the return code the way they want. Just want to point that the current test app could do without it, since it is quite simple, it waits for all, then checks all return codes. > Most of these functions are not marked as experimental since > we want applications to convert over asap. The one exception is > the return_code, which is only used by some tests now and not > clear that it is even that useful. > +1 diff --git a/lib/librte_eal/common/eal_common_lcore.c > b/lib/librte_eal/common/eal_common_lcore.c > index 1cbac42286ba..c3cf5a06269d 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; > +} > + > +int rte_lcore_to_cpu_id(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_id; > +} > + > +rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].cpuset; > +} > + > +unsigned > Ah, checkpatch does not complain for me, I would have expected a warning on "unsigned int". Can you fix it so that it matches the declaration from the header ? +rte_lcore_to_socket_id(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].socket_id; > +} > + > +int > +rte_lcore_return_code(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].ret; > +} > + > static int > socket_id_cmp(const void *a, const void *b) > { The rest looks fine. Reviewed-by: David Marchand -- David Marchand 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 D05FCA0096 for ; Tue, 9 Apr 2019 09:43:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A150E568A; Tue, 9 Apr 2019 09:43:12 +0200 (CEST) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by dpdk.org (Postfix) with ESMTP id D934D5592 for ; Tue, 9 Apr 2019 09:43:11 +0200 (CEST) Received: by mail-ua1-f43.google.com with SMTP id t15so524487uao.5 for ; Tue, 09 Apr 2019 00:43:11 -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; bh=ie/HijC8McJivm10IRTTTWhPRe5yCknyQZSfgPf1Jz8=; b=UVcb1c9VCEZrkk6tCUWx5n3Ln9tAXe99Nhe8GSLzX1Gp8f4pg8dU8zjdazS/5J8Zxg ds2ogF3fSbUAFrd4e/KSHj2PxzmbXwG35JuNacXSA1tfErNarF6b4O0ptxL6dnWvo5ZI ZNoIa+OvERhKgMBhPJAmNXNY21nW9hBjvZwLKu00QnbCkWoflEvqhObc5/SHNy5lOuEV 4V0jvYY0h85I9cZU59dwKO6J5Bh32MUEcxfPxnGvrflspdbWk7V66Wn7aV4OErSsb3Qf BmyFKbVphd6zWAFtlU8ZmH6ZlBJjZ8uZik+G0DUmVqN5BV3H3ohyd3zsVgRBm736k9P2 wBqA== X-Gm-Message-State: APjAAAUjp20tOYE6ZEChmmhX8/q6BGE+xIGrGbzJWa/iynW6jLcGD/gl jnaDW1pvp08crcb/QB9G9CG0qz/N4j+lsuzmfVbkErUt X-Google-Smtp-Source: APXvYqx6JTaZbLD3ZHlbDWvUKLW8PRh+l7kW6TI78lheZwJY+1RsySkN8vWT9O11PieldISfzbstefTIwIeUgs7sU5s= X-Received: by 2002:ab0:b05:: with SMTP id b5mr9827557uak.73.1554795791258; Tue, 09 Apr 2019 00:43:11 -0700 (PDT) MIME-Version: 1.0 References: <20190408182510.16078-1-stephen@networkplumber.org> <20190408182510.16078-2-stephen@networkplumber.org> In-Reply-To: <20190408182510.16078-2-stephen@networkplumber.org> From: David Marchand Date: Tue, 9 Apr 2019 09:43:00 +0200 Message-ID: To: Stephen Hemminger Cc: dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 1/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: <20190409074300.xtRiHWlNnrm4FTEOU8uzWeT5V2nH30aGIX9P26F5Dqk@z> On Mon, Apr 8, 2019 at 8:25 PM Stephen Hemminger wrote: > 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 the state and return code functions as experimental > since these values might change in the future and probably shouldn't > have been used by non EAL code anyway. > You removed the state function, no need to mention it. Since we already expose the state, exposing the ret code seems fair. Applications can wait themselves and check the return code the way they want. Just want to point that the current test app could do without it, since it is quite simple, it waits for all, then checks all return codes. > Most of these functions are not marked as experimental since > we want applications to convert over asap. The one exception is > the return_code, which is only used by some tests now and not > clear that it is even that useful. > +1 diff --git a/lib/librte_eal/common/eal_common_lcore.c > b/lib/librte_eal/common/eal_common_lcore.c > index 1cbac42286ba..c3cf5a06269d 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; > +} > + > +int rte_lcore_to_cpu_id(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_id; > +} > + > +rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].cpuset; > +} > + > +unsigned > Ah, checkpatch does not complain for me, I would have expected a warning on "unsigned int". Can you fix it so that it matches the declaration from the header ? +rte_lcore_to_socket_id(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].socket_id; > +} > + > +int > +rte_lcore_return_code(unsigned int lcore_id) > +{ > + return lcore_config[lcore_id].ret; > +} > + > static int > socket_id_cmp(const void *a, const void *b) > { The rest looks fine. Reviewed-by: David Marchand -- David Marchand