From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-f66.google.com (mail-vs1-f66.google.com [209.85.217.66]) by dpdk.org (Postfix) with ESMTP id D68D61B147 for ; Tue, 2 Apr 2019 22:15:51 +0200 (CEST) Received: by mail-vs1-f66.google.com with SMTP id d8so7560153vsp.2 for ; Tue, 02 Apr 2019 13:15:51 -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=L/K0ejZRz3rm8YZYgT3wE8CubJTjk6OBvt8gHfK+3YE=; b=bnpwfWLWnFAkS1xdUnoYxUfASGcFfXxHv5VCbjP4tf9lB3DKTPiv/LUf0DVOqHXrM8 WNSq4DjlXMYnvlplCrU6pMHJfcY/3iP7YqQHt8JZsMh1JO8kM0BSZ131mAihGuCqxXIG F0EEj0CWlZc6bTy7vY9tGrGO2aab5HuJWICDCF/vLzPo5WSaOXdXzMdsX5ZfDmpYVhqo 0nYLrD+IGxdicrNfQJAne7/7Jg76L6KWrCHb/LH4pZivCnolqtv0GIsZyp86HZrwhRZo 7xt8QEzLy/k6bIxU1V4dPxiigUo7kDLrTLK4LdTwVKdn8+pJvDBlPmW9LE5TKoUdZIU9 ApOw== X-Gm-Message-State: APjAAAUx59aL5PVFWz5/PhfidWAj4nqyMZFg0DSftUNH5lHKOItLGq5J a4e9GtOQIef1JrOs+mEP0p9PD7D6dBJhFyLyQdYeW2bVH4o= X-Google-Smtp-Source: APXvYqzkifUmqlVzYiux0xccci5Ea70iRHf5KtHBNM1zWLdITSwWzWHPuU0X2z8NyY/VEX6C0NW1tWbLZJCyL8OcEgI= X-Received: by 2002:a67:f607:: with SMTP id k7mr19530981vso.137.1554236151199; Tue, 02 Apr 2019 13:15:51 -0700 (PDT) MIME-Version: 1.0 References: <20190326192556.19934-1-stephen@networkplumber.org> <20190402155722.21400-1-stephen@networkplumber.org> In-Reply-To: <20190402155722.21400-1-stephen@networkplumber.org> From: David Marchand Date: Tue, 2 Apr 2019 22:15:40 +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 v2] eal: rename state values in rte_lcore_state 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, 02 Apr 2019 20:15:52 -0000 On Tue, Apr 2, 2019 at 5:57 PM Stephen Hemminger wrote: > C language does not really treat enum's as first class symbols. > The values in an enum live in a global namespace. That means if > DPDK defines "RUNNING" it can't be used by another enum in an > application using DPDK. > > To solve this add a prefix "RTE_LCORE_" to the enum values, and > make them grammatically consistent. > Well, I understand this is not clean, but this patch breaks the API. > Also, simplify the inline thread_is_running() which is copied > in softnic and ip_pipeline. > > Signed-off-by: Stephen Hemminger > --- > v2 - change prefix to RTE_LCORE_ > > drivers/event/octeontx/ssovf_evdev_selftest.c | 2 +- > drivers/event/sw/sw_evdev_selftest.c | 4 ++-- > drivers/net/softnic/rte_eth_softnic_thread.c | 5 +---- > examples/ip_pipeline/thread.c | 5 +---- > examples/l2fwd-keepalive/main.c | 2 +- > lib/librte_eal/common/eal_common_launch.c | 12 ++++++------ > lib/librte_eal/common/include/rte_launch.h | 6 +++--- > lib/librte_eal/common/rte_service.c | 2 +- > lib/librte_eal/freebsd/eal/eal_thread.c | 6 +++--- > lib/librte_eal/linux/eal/eal.c | 2 +- > lib/librte_eal/linux/eal/eal_thread.c | 8 ++++---- > 11 files changed, 24 insertions(+), 30 deletions(-) > Missed a few places: # should probably not access lcore_config directly... examples/bond/main.c: if (lcore_config[global_flag_stru_p->LcoreMainCore].state != WAIT) { examples/bond/main.c: if (lcore_config[slave_core_id].state != WAIT) # BSD must have trouble building lib/librte_eal/freebsd/eal/eal.c: lcore_config[i].state = WAIT; # I suppose most comments are quite useless, but still unaligned with your change examples/ip_pipeline/thread.c: * (B) Its data plane thread is in RUNNING state. lib/librte_eal/common/eal_common_launch.c: * Check that every SLAVE lcores are in WAIT state, then call lib/librte_eal/common/include/rte_eal.h: * It puts the SLAVE lcores in the WAIT state. lib/librte_eal/common/include/rte_launch.h: * is in the WAIT state (this is true after the first call to lib/librte_eal/common/include/rte_launch.h: * the RUNNING state, then calls the function f with argument arg. Once the lib/librte_eal/common/include/rte_launch.h: * execution is done, the remote lcore switches to a FINISHED state and lib/librte_eal/common/include/rte_launch.h: * - (-EBUSY): The remote lcore is not in a WAIT state. lib/librte_eal/common/include/rte_launch.h: * Check that each SLAVE lcore is in a WAIT state, then call lib/librte_eal/common/include/rte_launch.h: * - (-EBUSY): At least one remote lcore is not in a WAIT state. In this lib/librte_eal/common/include/rte_launch.h: * If the slave lcore identified by the slave_id is in a FINISHED state, lib/librte_eal/common/include/rte_launch.h: * switch to the WAIT state. If the lcore is in RUNNING state, wait until lib/librte_eal/common/include/rte_launch.h: * the lcore finishes its job and moves to the FINISHED state. lib/librte_eal/common/include/rte_launch.h: * - 0: If the lcore identified by the slave_id is in a WAIT state. lib/librte_eal/common/include/rte_launch.h: * FINISHED or RUNNING state. In this case, it changes the state lib/librte_eal/common/include/rte_launch.h: * of the lcore to WAIT. lib/librte_eal/common/include/rte_launch.h: * that all slave lcores are in a WAIT state. lib/librte_eal/freebsd/eal/eal_thread.c: * remote lcore switch in FINISHED state. lib/librte_eal/linux/eal/eal_thread.c: * remote lcore switch in FINISHED state. lib/librte_eal/linux/eal/eal_thread.c: /* when a service core returns, it should go directly to WAIT -- 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 29DFCA0679 for ; Tue, 2 Apr 2019 22:15:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6269A1B14C; Tue, 2 Apr 2019 22:15:53 +0200 (CEST) Received: from mail-vs1-f66.google.com (mail-vs1-f66.google.com [209.85.217.66]) by dpdk.org (Postfix) with ESMTP id D68D61B147 for ; Tue, 2 Apr 2019 22:15:51 +0200 (CEST) Received: by mail-vs1-f66.google.com with SMTP id d8so7560153vsp.2 for ; Tue, 02 Apr 2019 13:15:51 -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=L/K0ejZRz3rm8YZYgT3wE8CubJTjk6OBvt8gHfK+3YE=; b=bnpwfWLWnFAkS1xdUnoYxUfASGcFfXxHv5VCbjP4tf9lB3DKTPiv/LUf0DVOqHXrM8 WNSq4DjlXMYnvlplCrU6pMHJfcY/3iP7YqQHt8JZsMh1JO8kM0BSZ131mAihGuCqxXIG F0EEj0CWlZc6bTy7vY9tGrGO2aab5HuJWICDCF/vLzPo5WSaOXdXzMdsX5ZfDmpYVhqo 0nYLrD+IGxdicrNfQJAne7/7Jg76L6KWrCHb/LH4pZivCnolqtv0GIsZyp86HZrwhRZo 7xt8QEzLy/k6bIxU1V4dPxiigUo7kDLrTLK4LdTwVKdn8+pJvDBlPmW9LE5TKoUdZIU9 ApOw== X-Gm-Message-State: APjAAAUx59aL5PVFWz5/PhfidWAj4nqyMZFg0DSftUNH5lHKOItLGq5J a4e9GtOQIef1JrOs+mEP0p9PD7D6dBJhFyLyQdYeW2bVH4o= X-Google-Smtp-Source: APXvYqzkifUmqlVzYiux0xccci5Ea70iRHf5KtHBNM1zWLdITSwWzWHPuU0X2z8NyY/VEX6C0NW1tWbLZJCyL8OcEgI= X-Received: by 2002:a67:f607:: with SMTP id k7mr19530981vso.137.1554236151199; Tue, 02 Apr 2019 13:15:51 -0700 (PDT) MIME-Version: 1.0 References: <20190326192556.19934-1-stephen@networkplumber.org> <20190402155722.21400-1-stephen@networkplumber.org> In-Reply-To: <20190402155722.21400-1-stephen@networkplumber.org> From: David Marchand Date: Tue, 2 Apr 2019 22:15:40 +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 v2] eal: rename state values in rte_lcore_state 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: <20190402201540.-folIS1cN0nV8DL1o0YV7Mg7jwrL6DY0c6Hx29afSII@z> On Tue, Apr 2, 2019 at 5:57 PM Stephen Hemminger wrote: > C language does not really treat enum's as first class symbols. > The values in an enum live in a global namespace. That means if > DPDK defines "RUNNING" it can't be used by another enum in an > application using DPDK. > > To solve this add a prefix "RTE_LCORE_" to the enum values, and > make them grammatically consistent. > Well, I understand this is not clean, but this patch breaks the API. > Also, simplify the inline thread_is_running() which is copied > in softnic and ip_pipeline. > > Signed-off-by: Stephen Hemminger > --- > v2 - change prefix to RTE_LCORE_ > > drivers/event/octeontx/ssovf_evdev_selftest.c | 2 +- > drivers/event/sw/sw_evdev_selftest.c | 4 ++-- > drivers/net/softnic/rte_eth_softnic_thread.c | 5 +---- > examples/ip_pipeline/thread.c | 5 +---- > examples/l2fwd-keepalive/main.c | 2 +- > lib/librte_eal/common/eal_common_launch.c | 12 ++++++------ > lib/librte_eal/common/include/rte_launch.h | 6 +++--- > lib/librte_eal/common/rte_service.c | 2 +- > lib/librte_eal/freebsd/eal/eal_thread.c | 6 +++--- > lib/librte_eal/linux/eal/eal.c | 2 +- > lib/librte_eal/linux/eal/eal_thread.c | 8 ++++---- > 11 files changed, 24 insertions(+), 30 deletions(-) > Missed a few places: # should probably not access lcore_config directly... examples/bond/main.c: if (lcore_config[global_flag_stru_p->LcoreMainCore].state != WAIT) { examples/bond/main.c: if (lcore_config[slave_core_id].state != WAIT) # BSD must have trouble building lib/librte_eal/freebsd/eal/eal.c: lcore_config[i].state = WAIT; # I suppose most comments are quite useless, but still unaligned with your change examples/ip_pipeline/thread.c: * (B) Its data plane thread is in RUNNING state. lib/librte_eal/common/eal_common_launch.c: * Check that every SLAVE lcores are in WAIT state, then call lib/librte_eal/common/include/rte_eal.h: * It puts the SLAVE lcores in the WAIT state. lib/librte_eal/common/include/rte_launch.h: * is in the WAIT state (this is true after the first call to lib/librte_eal/common/include/rte_launch.h: * the RUNNING state, then calls the function f with argument arg. Once the lib/librte_eal/common/include/rte_launch.h: * execution is done, the remote lcore switches to a FINISHED state and lib/librte_eal/common/include/rte_launch.h: * - (-EBUSY): The remote lcore is not in a WAIT state. lib/librte_eal/common/include/rte_launch.h: * Check that each SLAVE lcore is in a WAIT state, then call lib/librte_eal/common/include/rte_launch.h: * - (-EBUSY): At least one remote lcore is not in a WAIT state. In this lib/librte_eal/common/include/rte_launch.h: * If the slave lcore identified by the slave_id is in a FINISHED state, lib/librte_eal/common/include/rte_launch.h: * switch to the WAIT state. If the lcore is in RUNNING state, wait until lib/librte_eal/common/include/rte_launch.h: * the lcore finishes its job and moves to the FINISHED state. lib/librte_eal/common/include/rte_launch.h: * - 0: If the lcore identified by the slave_id is in a WAIT state. lib/librte_eal/common/include/rte_launch.h: * FINISHED or RUNNING state. In this case, it changes the state lib/librte_eal/common/include/rte_launch.h: * of the lcore to WAIT. lib/librte_eal/common/include/rte_launch.h: * that all slave lcores are in a WAIT state. lib/librte_eal/freebsd/eal/eal_thread.c: * remote lcore switch in FINISHED state. lib/librte_eal/linux/eal/eal_thread.c: * remote lcore switch in FINISHED state. lib/librte_eal/linux/eal/eal_thread.c: /* when a service core returns, it should go directly to WAIT -- David Marchand