From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f65.google.com (mail-pg0-f65.google.com [74.125.83.65]) by dpdk.org (Postfix) with ESMTP id F2B4E4C57 for ; Tue, 24 Apr 2018 17:04:21 +0200 (CEST) Received: by mail-pg0-f65.google.com with SMTP id a13so6630211pgu.4 for ; Tue, 24 Apr 2018 08:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xphCQ9UsZebC8UBwcm9tbBu/Xc4Irj0liYZ0hn4LOuQ=; b=B9UnZb/5FEnNxts4Qzyfrz7gsn0QhTmhI5U/yiKXBToEkDEHFW4hUzjx9rc1maVNcg 2XyFiBCoXVjj9luF2qKquH8rzd/KvfODEnjlv8sV1EkaLfcD6H4vyFjuT2VOlF0TslL5 TvsPA7IJVUsGEpQQbJafTwXCkLvmxeuEg7s8GOE3Uyv1QdJjYNqk/psnUjEpP68cDBGy McPOddGgwwOCTpmOjZZFzDAfKpzzHx6T3KdYznc8RFPytA73Fka298TGqcL6HQDfmdT8 v5HY7DfoDRIgomMX/wfbSjbGb2+uOpmQb+d3mE7KH4+3zh9mUi17NqCLrVkD39q07zw4 /YZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xphCQ9UsZebC8UBwcm9tbBu/Xc4Irj0liYZ0hn4LOuQ=; b=Kf/xpCflIFzPTA/J0q0Lcp8Jfdo3uG3mWBRSgZU0efiyXQKOWmBoKPI/33wiWM4yBk 11gVxNxsE2YMKUHsFAinLOdc6UbRQtYyF9JDghbGVrdfLWcui2AXjWngW3rk1pWYhWt9 A68NIm+c9m6ksHfjo/UBrrQSmXtERBaVpViJzuZUkxMt/SKK+PKoDtuLGq5o+Al3zyYp jlLh28CP0rsiQYjzEjqk+buOvdEz/uNhBTqk/Ukpb8Int+deUnr6ejL1dou52NLxQFFU Z/6iPq3TAsNrmmiilmeY7hEFDrgUzVG6kToXZjbrviLh6/SYJPtJ+gHRV+82P2BjEEOh 4Tng== X-Gm-Message-State: ALQs6tDXlYjhrVFv1LwlGjBn5mwzQcaT5yOtQCDgi2xTb9dlqIlVv7f1 5EcCvx8PEiPiyknntnRH8qY0hh31XhiUVIGeUtIKXQ== X-Google-Smtp-Source: AIpwx4/ERWBph2nuGzlkD7HDu16MxEQbfBEymfcDLX8vDGV35e2DFlcoOVaLHX5WSR+CKPguTJ7HEzusgH5DzYLzwhc= X-Received: by 10.99.190.67 with SMTP id g3mr18315458pgo.53.1524582260523; Tue, 24 Apr 2018 08:04:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.140.145 with HTTP; Tue, 24 Apr 2018 08:04:19 -0700 (PDT) In-Reply-To: <20180423181411.68dadcef@xeon-e3> References: <20180423165039.51393aad@xeon-e3> <20180423173034.7086b772@xeon-e3> <20180423181411.68dadcef@xeon-e3> From: Brijesh Singh Date: Tue, 24 Apr 2018 08:04:19 -0700 Message-ID: To: Stephen Hemminger Cc: Jim Murphy , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] rte_hash thread safe 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, 24 Apr 2018 15:04:22 -0000 Thank you all for explaining. My updates are uncommon; Adding concept of quiescent threads should be worst case loss of 1 full burst cpu cycles on the threads. This should be acceptable infrequent delay in packet processing. I need data on performance of librcu lookups under infrequent updates, if the difference is not significant on x86, I will use librcu. On Mon, Apr 23, 2018 at 6:14 PM, Stephen Hemminger wrote: > On Mon, 23 Apr 2018 17:48:50 -0700 > Jim Murphy wrote: > >> Anecdotally I've heard that the urcu hash implementation is slower than >> rte_hash based on pure lookup performance. Has anyone considered adding RCU >> hooks into rte_hash? > > > Not really possible with DPDK (as I said earlier) because DPDK does not have concept > of thread quiescent period to allow for safe deletion. You could manually use RCU > concepts of RCU and RTE hash; it would require using userspace RCU primitives > inside DPDK. This would cause a dependency that would prevent that from ever > being merged upstream due to license conflict; but since DPDK is liberal BSD > license you are free to do it and maintain it on your own.