From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by dpdk.org (Postfix) with ESMTP id 674FA374 for ; Wed, 25 Apr 2018 08:45:44 +0200 (CEST) Received: by mail-qk0-f174.google.com with SMTP id c70so12950852qkg.0 for ; Tue, 24 Apr 2018 23:45:44 -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=aQE/4UNcmh3xNFG2XLLAvL69f3Our7p0AQ0phn0Wb5M=; b=C5GTNntNO1kM3klgSuta3Gc7XENVL1k8MrHL6tXmy5CmXnlGzxjvsCafDIsfAQ53qf MgBypKCqFu4oh10TLKaZ1UNsMJRgcfzkkj1zuksUKnql8Ec/LQGICujc/bncTs7jclaZ y3trE8EYlRB1DEQds/m7S7OUyaFU1QfYWnXpigcORcs01ynbGvE0kxRXHgWV6FBKUUI1 9b6Z+pryfEI9KD4KWGNd49NthhVnBFeUmvcxy/QjwoYAYGkCI8gG5Y7HR7tC73tIEKn+ 0lIJUeuwXU1IVkIJlbsJw6Vsqrcak1LyiB0l4nQs+ldFE/MvOGXTnJJvYRMrwf7vrLr1 LAXQ== 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=aQE/4UNcmh3xNFG2XLLAvL69f3Our7p0AQ0phn0Wb5M=; b=pT+3PIawbtoEpDoA7Wg1JEZD/aoENFj60oeaIJ8amoB5eF3zAMe43oAZvYm++jsMqC 96aBinREufHKoOT2yppkLifJO9TSyn7bAYFlcDSBzf1jG/VIpdziHRdrJRqMVaagCW3d vr0QC+0+v89jJweLzVZizlq+K5foLcZU0Z9Dv0oKGtuMA7ouCzxA34z8JlpdhjGXnYtU P4TWD9YvywhgoNDdzZZCv6jX8q3hFQRQ8hB9KFAb+DbHm7s+VH1EKC9TLZhyykyE+Zst o0f+Gnz2sT/JnMyxBZA3wvLMr3t1n4UdfPXdQNFzhBax9/RqHoVf/cI7VmGJns+lRZ2T Kc+w== X-Gm-Message-State: ALQs6tA7ZVpJWcfntdlCMwuyC/yNZPo58zRibPhtHSqFYktWb+Dc/+ib n0yeQ+pD28GOndHNUEYjXo7Du4pyEJf12N3RZXM= X-Google-Smtp-Source: AB8JxZry0423Pz/kAyrGSdC25MRBLt7JwAK9MHEuJZDQqRTj+7L5CzGCnwMNUy1yhwgXEid4axEuZkUyj6bQOA1ciEM= X-Received: by 10.55.164.2 with SMTP id n2mr27831282qke.298.1524638743620; Tue, 24 Apr 2018 23:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.154 with HTTP; Tue, 24 Apr 2018 23:45:43 -0700 (PDT) In-Reply-To: References: <20180423165039.51393aad@xeon-e3> <20180423173034.7086b772@xeon-e3> <20180423181411.68dadcef@xeon-e3> From: Shyam Shrivastav Date: Wed, 25 Apr 2018 12:15:43 +0530 Message-ID: To: Brijesh Singh Cc: Stephen Hemminger , Jim Murphy , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Wed, 25 Apr 2018 06:45:44 -0000 You can look at hash table support under librte_table, we are using it for tcp stateful and syncache table (16 bytes key), supports optimized burst look ups, pretty good performance at line rate with up to half a billion entries in syn cache lru table and 33 million in flows ext table. However these tables are pre-allocated and not thread safe (tradeoff with performance), we use per core tables if running multicore .... *I thank all creators/contributors involved, it definitely been huge help in my project * On Tue, Apr 24, 2018 at 8:34 PM, Brijesh Singh wrote: > 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. >