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 6DED4A00E6 for ; Tue, 16 Apr 2019 16:54:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C38711B4E7; Tue, 16 Apr 2019 16:54:22 +0200 (CEST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id 91D3E1B4ED for ; Tue, 16 Apr 2019 16:54:20 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id z5so10540093pfn.3 for ; Tue, 16 Apr 2019 07:54:20 -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=gy4rcs7DM4UpGLUMUvg4+vTWIZPrijB/2M61XNLlb9E=; b=pdCTIUYglaxrHpotQRcfK5dkh+4gKVrV1HtRh+SdkgARAtQ3gJk1G0Ho35J535ShH0 ZaTmZY6naaHRXDjR3eoKwlOOYttmWKnZgVTE7JW0YIBUXRpw520OXXKadqBw+Y3JL3p6 w0Oj90ZCD6ILvtKUXZGKRAUN7/8YrMq+ekp1nPw4DnSyWd9bQZE9h7FQJFn57K4YdECG n+FqAiXtaWHZc/Rr7ca6fzLPtfiuS+fBVlaAK+YCbprmzDpDgU/SIGpfV9hKjSCVMSnd +QlSFa0dx00U+9s0F9z7+niuV0s6wDrfstALkc12RSag/9Iiagd8pd/+9yFE+TF4ngJW SOkQ== 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=gy4rcs7DM4UpGLUMUvg4+vTWIZPrijB/2M61XNLlb9E=; b=dpIaB2wfL2hJ9P6yH+NaIPrCn0Cv/iqjXNe7ivDdwtQpn/fClik+Ji+4faYbcfPyb4 oygy6CYLnneyqY6Uvsh5rvchpP5nz4cwNuDARl6fK9YuOkk41Lg1kPE/5PlD/2ps7eF/ mSnl8b20Go9PpZErZzX2pijHThhnRNRltjKWSUBms39C3u807xvp0H1aVRZehpLShF2D Ko1Ar54GiF22UirMbFtmNzZFidMPJ7x412hPcR/+gAr8E1yUoot+Bl00P3WvYUspwv79 29W1vY2vzqY3/RrYUPx3uQLP6L1kgt/tXSKnQzPbMABflLxV9Qi4EkticVX148MoOG1s KYzQ== X-Gm-Message-State: APjAAAVbgbQr+JRTp6SapEPmLwnrzWBMHlYgfxdkFk0y+4U7GH/ZuEQn WHDdwHyxa2d7mSx0oKmez67cZw== X-Google-Smtp-Source: APXvYqzjHaWMFhkMmHkyG9fAjbNra5VE5ysIPIhlK3+NtycCQ1xr5WSxnYNNHnqJuRtHqeRScHd2xQ== X-Received: by 2002:a62:12c9:: with SMTP id 70mr83960368pfs.156.1555426459714; Tue, 16 Apr 2019 07:54:19 -0700 (PDT) Received: from xps13.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id a129sm107698878pfa.152.2019.04.16.07.54.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 07:54:19 -0700 (PDT) Date: Tue, 16 Apr 2019 07:54:15 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: "Ananyev, Konstantin" , "paulmck@linux.ibm.com" , "Kovacevic, Marko" , "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , Dharmik Thakkar , Malvika Gupta , nd Message-ID: <20190416075415.76c9d64a@xps13.lan> In-Reply-To: References: <20181122033055.3431-1-honnappa.nagarahalli@arm.com> <20190412202039.46902-1-honnappa.nagarahalli@arm.com> <20190412202039.46902-2-honnappa.nagarahalli@arm.com> <20190412150650.3709358e@shemminger-XPS-13-9360> <20190412160629.670eacd1@shemminger-XPS-13-9360> <2601191342CEEE43887BDE71AB9772580148A97E53@irsmsx105.ger.corp.intel.com> <20190415083834.31b38ed3@shemminger-XPS-13-9360> <2601191342CEEE43887BDE71AB9772580148A98064@irsmsx105.ger.corp.intel.com> <20190415142631.4c250248@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism 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: <20190416145415.zZPxSaG3OuV8aYhYEkIIK39mi-xMVrOO4cYKM1Y3BvI@z> On Tue, 16 Apr 2019 05:29:21 +0000 Honnappa Nagarahalli wrote: > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Add RCU library supporting quiescent state based memory > > > > > > > > > reclamation > > > > > > > > method. > > > > > > > > > This library helps identify the quiescent state of the > > > > > > > > > reader threads so that the writers can free the memory > > > > > > > > > associated with the lock less data structures. > > > > > > > > > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > > > > > > > > > > > > > > Reviewed-by: Steve Capper > > > > > > > > > Reviewed-by: Gavin Hu > > > > > > > > > Reviewed-by: Ola Liljedahl > > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > > > > > > > > > > > > > > > > After evaluating long term API/ABI issues, I think you need > > > > > > > > to get rid of almost all use of inline and visible > > > > > > > > structures. Yes it might be marginally slower, but you thank me > > the first time you have to fix something. > > > > > > > > > > > > > > > Agree, I was planning on another version to address this (I am yet > > to take a look at your patch addressing the ABI). > > > > > > > The structure visibility definitely needs to be addressed. > > > > > > > For the inline functions, is the plan to convert all the > > > > > > > inline functions in DPDK? If yes, I think we need to consider > > > > > > > the performance > > > > > > difference. May be consider L3-fwd application, change all the > > inline functions in its path and run a test? > > > > > > > > > > > > Every function that is not in the direct datapath should not be > > inline. > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > > > packet alloc/free > I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever). > > > > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > > > > I think rcu should be one of such exceptions - it is just another > > > > > synchronization mechanism after all (just a bit more sophisticated). > > > > > Konstantin > > > > > > > > If you look at the other userspace RCU, you wil see that the only > > > > inlines are the rcu_read_lock,rcu_read_unlock and > > rcu_reference/rcu_assign_pointer. > > > > > > > > The synchronization logic is all real functions. > > > > > > In fact, I think urcu provides both flavors: > > > https://github.com/urcu/userspace- > > rcu/blob/master/include/urcu/static/ > > > urcu-qsbr.h I still don't understand why we have to treat it > > > differently then let say spin-lock/ticket-lock or rwlock. > > > If we gone all the way to create our own version of rcu, we probably > > > want it to be as fast as possible (I know that main speedup should > > > come from the fact that readers don't have to wait for writer to > > > finish, but still...) > > > > > > Konstantin > > > > > > > Having locking functions inline is already a problem in current releases. > > The implementation can not be improved without breaking ABI (or doing > > special workarounds like lock v2) > I think ABI and inline function discussion needs to be taken up in a different thread. > > Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon. > > If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used. > > typedef void * rte_rcu_qsbr_t; > typedef void * rte_hash_t; > > But it requires typecasting. > > [1] http://patchwork.dpdk.org/cover/52609/ C allows structure to be defined without knowing what is in it therefore. typedef struct rte_rcu_qsbr rte_rcu_qsbr_t; is preferred (or do it without typedef) struct rte_rcu_qsbr;