From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f67.google.com (mail-it0-f67.google.com [209.85.214.67]) by dpdk.org (Postfix) with ESMTP id 88DB1235 for ; Fri, 17 Aug 2018 14:52:03 +0200 (CEST) Received: by mail-it0-f67.google.com with SMTP id d10-v6so11073391itj.5 for ; Fri, 17 Aug 2018 05:52:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hsDknOw5Ta5QlVl4ieVRud3R+Z3IURbVBdngNHtGS9g=; b=PH1yzie07zY60SmTqTx6Eof/PdFGu0qUH1o97lc81B+GG/ZAhvfacc3eY1WppT/tw4 Gkbkyr0zld4y55zLkAOU3cxqDqW+1Xn3ScKtGmVD2SOa+RzQu6TqXc/BL9ZlXTrBecWE 2eQaVm46B1ixGtIKFjmdDbRJYBQueD+IkLyYu9d1MOmjLGCRghoyu6PNsrNvnR6U9D+o g6SrA5a6ODeGSK6MhdC944V7krgvNV7owc8UP3EM09cO9CYMJM6ukSgzUzuMIBb+YcOw X0ficpWj9NhvjVGGaVJTVKbLgOS2YrhfMqRZkBSXBAEXmroDpfL7qwnfzlyYPI4nQhwr JBwA== X-Gm-Message-State: AOUpUlEC3wzJd5PyFn97dnSmZYLvVNiOYWC9dx8KvtQW4/pII8F1mEpJ zT24H0JWmBrVbCHv9S4W4p3sjK8G3zgGLybL+WA= X-Google-Smtp-Source: AA+uWPzZSa/cNT6CNpd10/MuJzzHRPULAbgM2vpbu6uEx2xmiPvh9XJRFOGs7LiQyRft21CsFDWtp2NMPW54QcydRPY= X-Received: by 2002:a24:141:: with SMTP id 62-v6mr24016534itk.97.1534510322806; Fri, 17 Aug 2018 05:52:02 -0700 (PDT) MIME-Version: 1.0 References: <1528455078-328182-1-git-send-email-yipeng1.wang@intel.com> <20180711134907.01d8eaf0@xeon-e3> <4478633.7AMRLkzmKO@xps> In-Reply-To: From: ASM Date: Fri, 17 Aug 2018 15:51:51 +0300 Message-ID: To: yipeng1.wang@intel.com Cc: thomas@monjalon.net, stephen@networkplumber.org, dev@dpdk.org, pablo.de.lara.guarch@intel.com, bruce.richardson@intel.com, honnappa.nagarahalli@arm.com, vguvva@caviumnetworks.com, brijesh.s.singh@gmail.com, ren.wang@intel.com, sameh.gobriel@intel.com, charlie.tai@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v5 5/8] hash: add read and write concurrency support 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: Fri, 17 Aug 2018 12:52:03 -0000 > I guess the try-locks still does not solve the overhead of multiple reade= rs contending the counter. It just provides a non-blocking version of the = same algorithm. DPDK project does not use any rwlock for solving any overhead problem of multiple reader (at least I did not find it). For non-critical sections it is often easier to write via rwlock (for to simplify the code). The try locks, relock to read and other are use only for even more simplifies uncritical code. For example some process need change data (write lock), then reread the contents (read lock), it can release write and lock read, but relock to read is easier. Process in the write section can switch to read context and give control for reader function. I sought by third-party solution for rwlock, and decided that rte_rwlock is the best choice for it, especially if there is a relock to read, and try locks. P.S. For solving the overhead problem of multiple readers (if using of locks is _extremely_ required), best practice may be MCS lock and rwlock based on the MCS locks. --- Best regards, Leonid Myravjev On Fri, 13 Jul 2018 at 04:55, Wang, Yipeng1 wrote: > > Thanks for pointing me to this patch. > > I guess the try-locks still does not solve the overhead of multiple reade= rs contending the counter. It just provides a non-blocking version of the = same algorithm. > > The relock function looks interesting. But it would be helpful if any spe= cial use case or example is given. Specifically, who should call this funct= ion, the reader or the writer? Leonid, could you provide more context? > > The TLRW example I gave is potentially a better rw-lock algorithm. Paper = Reference: D. Dice and N Shavit. "TLRW: return of the read-write lock". In= such scheme, readers won't contend the same reader counter which introduce= s heavy cache bouncing that Stephen mentioned. Maybe we should introduce s= imilar algorithm into rte_rwlock library. > > >-----Original Message----- > >From: Thomas Monjalon [mailto:thomas@monjalon.net] > >Sent: Thursday, July 12, 2018 1:30 PM > >To: Wang, Yipeng1 ; Stephen Hemminger > >Cc: dev@dpdk.org; De Lara Guarch, Pablo = ; Richardson, Bruce ; > >honnappa.nagarahalli@arm.com; vguvva@caviumnetworks.com; brijesh.s.singh= @gmail.com; Wang, Ren ; > >Gobriel, Sameh ; Tai, Charlie > >Subject: Re: [dpdk-dev] [PATCH v5 5/8] hash: add read and write concurre= ncy support > > > >12/07/2018 03:22, Wang, Yipeng1: > >> From: Stephen Hemminger [mailto:stephen@networkplumber.org] > >> > >> > For small windows, reader-writer locks are slower than a spin lock > >> > because there are more cache bounces. > >> > >> Hi, Stephen, > >> > >> You are correct and we understand that spinlock might be slightly fast= er than counter based rwlock in this case. However, the > >counter based rwlock is the exception path when TSX fails. > >> > >> If performance of this exception path is a big concern, a more optimal= read-write lock scheme (e.g. TLRW) should be introduced into > >rte_rwlock in the future. > > > >Something like this? > > eal/rwlocks: Try read/write and relock write to read locks added > > https://patches.dpdk.org/patch/40254/ > > > > >