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 AD37CA054F; Mon, 1 Mar 2021 17:42:04 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2BD0E22A2D5; Mon, 1 Mar 2021 17:42:04 +0100 (CET) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id 5B1EB40041 for <dev@dpdk.org>; Mon, 1 Mar 2021 17:42:02 +0100 (CET) Received: by mail-pl1-f174.google.com with SMTP id z7so10252839plk.7 for <dev@dpdk.org>; Mon, 01 Mar 2021 08:42:02 -0800 (PST) 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=3l7GPvDQuMMN7YqGdUNuHoOKcUFULKaqCWvB/Z4AiYk=; b=Ekwx4cQNnG6pvWyAXTpfKGyyIYoRQHfqW4x7UaDIe3UEPqD0nzek1AU2QCqJX990JZ 0NheqewrHjQ6la34RfmtJpzA3DF5S5tt27MRI34gvHpaEFTUEUwo+oWrhPqBRNoTXgRV xgQbqnqZiHBznCZao+lH9P72QInLdFvbppwRPc5WMCw9d1fOTrhJa0RvX0TWQSOKEDN1 2dcshXdVtgmQlEi9VjP5PFztVddtqguAIy25w8NcyNvIhSTncpGTu115QhZdiYLt4BSq LNe1d63RnsH4ZzoU0UqHAetS36b9Rqjz4Frdx0IahdwTX+TnU5gs0H5v3feRzNTGQxeg 8SSg== 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=3l7GPvDQuMMN7YqGdUNuHoOKcUFULKaqCWvB/Z4AiYk=; b=JNBQpq9tUHi5k4GuMRDG3/w4MEucdVvn+Vx/9AXiPGVDOr9UeuCp7g4cgErG55d77L vqIui5Vkr0oZ+lvQChI0hUJZd5CkKjF020IpboxEDYgfUPZy0MidxbBg7rwyUKx5edDz mXpGnIbkWjqvZXryfhJNkPr4glg9a75xy0puAlTrc74wYS8Bz+7/RK+UsM1xCIIKJqdb cmy9vpCYwLqwHGsvQzlqhYk5HabdqSTn+aNfEk8yNDiqXtgIbozrPFWf2X+uZp/M1isM 1vIRZn8764aVLPuRN3l1T9TzZ2FN0hJWjEPQF6tEI28d9dVKQZNKRiCTNWWlNPa0+TSI 7hzA== X-Gm-Message-State: AOAM533muaF5A9NxqfUvtF8keQl6bubAF+Tq4g36ISkAh3Jc/SspSG8L xtmFzgEY8ZUJS1iiyErXuwQHoQ== X-Google-Smtp-Source: ABdhPJwDNJdjpZoVPnYQhq5D2xnym6pSI2FDGNbLsuBd4MZnf6my5/+4gQJW/f/HvSUx7Q0Li4/UWA== X-Received: by 2002:a17:902:369:b029:e4:b5f1:cfb4 with SMTP id 96-20020a1709020369b02900e4b5f1cfb4mr4681209pld.60.1614616921506; Mon, 01 Mar 2021 08:42:01 -0800 (PST) Received: from hermes.local (76-14-218-44.or.wavecable.com. [76.14.218.44]) by smtp.gmail.com with ESMTPSA id s4sm12825524pji.2.2021.03.01.08.42.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Mar 2021 08:42:01 -0800 (PST) Date: Mon, 1 Mar 2021 08:41:53 -0800 From: Stephen Hemminger <stephen@networkplumber.org> To: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> Cc: dev@dpdk.org, ruifeng.wang@arm.com, feifei.wang@arm.com, nd@arm.com Message-ID: <20210301084153.50b1c397@hermes.local> In-Reply-To: <20210224212018.17576-1-honnappa.nagarahalli@arm.com> References: <20210224212018.17576-1-honnappa.nagarahalli@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/5] Use correct memory ordering in eal functions 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 Wed, 24 Feb 2021 15:20:13 -0600 Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote: > rte_eal_remote_launch and rte_eal_wait_lcore need to provide > correct memory ordering to address the data communication from > main core to worker core and vice versa. > > There are 2 use cases: > 1) All the store operations (meant for worker) by main core > should be visible to worker core before the worker core runs the > assigned function > > 2) All the store operations by the worker core should be visible > to the main core after rte_eal_wait_lcore returns. > > For the data that needs to be communicated to the worker after > the rte_eal_remote_launch returns, load-acquire and store-release > semantics should be used (just like any other writer-reader use case). > > For the main to worker communication, the pointer to function > to execute is used as the guard variable. Hence, resetting of > the function pointer is important. > > For the worker to main communication, the existing code uses the > lcore state as the guard variable. However, it looks like > the FINISHED state is not really required. Hence the FINISHED state > is removed before using the state as the guard variable. I would like > some feedback on why the FINISHED state is required. I have not > paid attention to what it means for backward compatibility. > If it is decided to remove this state, documentation changes are > required. > Most likely all use of volatile in DPDK is suspect. Perhaps we should re-enable the "volatile considered harmful" warning in checkpatch