From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id 6D0F4F3E for ; Tue, 24 Apr 2018 04:13:07 +0200 (CEST) Received: by mail-wr0-f169.google.com with SMTP id p5-v6so18456261wre.12 for ; Mon, 23 Apr 2018 19:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JGbTwOo98SiNULfz+UaZGtKh2HLPQezy+x+uvbjp6bY=; b=c3SXHjEhNihWAFxbwSKrd5ARHrp4lvjOKMpL+LswM3oSzSUZZVooD+XKZe/3KOyKsy Ux58kjGvb40hrntL8DH2DLCY///Tsmy+9jizGD0QDtCFFx5JwAkAIe66XYvmjkKLMKHt X6WtW15MOBxYBOzNphM6J8C6087Q2Dx3qrfZPoCmZrfsIvs6B0RQbiCGqbIPOafZCqEW ld/kAXotowjkQn2A/XddOY7ihKyCArZ3J7AzSQWsXg9cToRB5Cz7G+ha2dUZZoYWcc9j gNtLeZZX9geOdrh66MiUxorubQyU+m+gboAorm6NKKFg7IF//JtrQR1I26lbW3LDcrLy s1qA== 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=JGbTwOo98SiNULfz+UaZGtKh2HLPQezy+x+uvbjp6bY=; b=KurbljShZ58APNBoRj8Ecs767iTkfUQsouIf5vu5xY1dRfL4Py7PR5EKXjqlrzOsVx k24/VXmPeJgV+KaycHXY7PqGfSDlfDz4sddYYNyaVgDLVr8UzkcIrViVZtFDHTd3r4oo wzBlTQv7hklazmh1+ZXycf9l30+1/LwAD/10XdW9XYg5EZnciNKrpbob8mVKXm4cJ/F2 J5inHrN8oAHz66iMIzaQ0vlDloUD+ArlBPkzxQVRpPVu76kjv8V9kig8CySzIFlb4uuI 0JEWvwMhVdnaixLdYpnjIpge6m48ACwo6gD3owM7jl8/drcndCL4CEtenjaxIeuO/uMZ TQOw== X-Gm-Message-State: ALQs6tACMslBHhJ9WX/BGwTAgD6cOty8FpciQl3+OxU/iCsLgySCs75L 9o+itj/8yJ2zHYcVUja5WmJhMXRbR77rHrMWJL+3SA== X-Google-Smtp-Source: AB8JxZqKEGENhgT7ddaWOdd5hBhBxN6EyrQrjqz1uUevxLUruvB/xe+B9xGK9oQ+4S/X+EAr2LHlcOooiJ4KLkQWcbI= X-Received: by 10.28.126.141 with SMTP id z135mr11178372wmc.6.1524535986707; Mon, 23 Apr 2018 19:13:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.245 with HTTP; Mon, 23 Apr 2018 19:13:06 -0700 (PDT) In-Reply-To: <20180423181411.68dadcef@xeon-e3> References: <20180423165039.51393aad@xeon-e3> <20180423173034.7086b772@xeon-e3> <20180423181411.68dadcef@xeon-e3> From: Jim Murphy Date: Mon, 23 Apr 2018 19:13:06 -0700 Message-ID: To: Stephen Hemminger Cc: Brijesh Singh , 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: Tue, 24 Apr 2018 02:13:07 -0000 Right, the threads using the DPDK libraries must do the right RCU stuff, declare quiescent, etc. I mentioned hooks to address the licensing issue. So for places in rte_hash were synchronization must be done a no-op function could be called but users could replace that function with one of their choosing. Thanks, Jim On Mon, Apr 23, 2018 at 6:14 PM, Stephen Hemminger < stephen@networkplumber.org> 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. >