From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D257EA0577; Mon, 13 Apr 2020 16:29:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 342CD1B53; Mon, 13 Apr 2020 16:29:47 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 36142F72 for ; Mon, 13 Apr 2020 16:29:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586788185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qp2y5z0cRI+FK9+IKqhwYGuL0kFe2UZpBowaPHCsAF8=; b=RylvIomXMn+5ZPiyO2UCuDJgge9r1rOBog1QS4maRuLwrcPdhB5+Q1Asd/EGhXRLoQNNgm RtW9OlRm3J/QCugcZCvRHDix6Zyj3Ut/iJGGtj/KaUis4NzsCDj0pWPQZpwEF/AM6DdNLV 3uUU3kcgCT3Yzej2lbnuI/agTm6i3+c= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-131-f2pUojugMqiD4zPIwiiZJg-1; Mon, 13 Apr 2020 10:29:42 -0400 X-MC-Unique: f2pUojugMqiD4zPIwiiZJg-1 Received: by mail-ua1-f72.google.com with SMTP id o17so3941832uaj.16 for ; Mon, 13 Apr 2020 07:29:42 -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; bh=/Mz1X0YojnWuZjdx6oUaW3psRgCFqv97b8M+6Hp7FNk=; b=JxbkKxR+Q8QHBAXAGuFgXwAQMbFXTkxxbbjShAGCI6mpyClXVnkYnZAjdQ18JrSbhI hj27ih0Tc9U7G/qSxsWjRco9cSFuGZtX5zLeio6xilbRaYhVAxauZ/xeiM0IqPrtRvL7 jNUNqe+B+rOyomPgx7Pjk06vRK6cR4Lql1F717jpoD0REeclMnwIP10t84kGiRRdd9S8 mq0+28UbCSqbC88fOVqKryzQ61IGE7/h82S/nR6yMWQROPfZvfWH/pi6lKcKoAN5+2NM +nVvCbpgGQESqPNnbnj+YzBT2eUVXs+YcR9uHluiDGzM1MBCxLN2Q93I9pykLOrzg3Si tzvA== X-Gm-Message-State: AGi0PuYG0MIrFudJYD7rbx8Vsh6FblAB7xJvJZoMsk95tsZ4JswKoJIJ B8jSRz7BIMYC24af/Ksl6gJ7mIG8MM0rCP18CcVTexRTD1KZS/3EUn+xdljHwBY6QS4Thi0i7OI 0egkPxYK2hAkJwS1aEMs= X-Received: by 2002:a1f:3649:: with SMTP id d70mr10760856vka.12.1586788181600; Mon, 13 Apr 2020 07:29:41 -0700 (PDT) X-Google-Smtp-Source: APiQypIJ1BVyRjD4y0NS1AZH9rZPib6n9vCGVfbXhfALAGXhCYfztIRGrq0NrjPnUDzfefOxBjma689uGwrB5RiA5dg= X-Received: by 2002:a1f:3649:: with SMTP id d70mr10760831vka.12.1586788181276; Mon, 13 Apr 2020 07:29:41 -0700 (PDT) MIME-Version: 1.0 References: <20200402220959.29885-1-konstantin.ananyev@intel.com> <20200403174235.23308-1-konstantin.ananyev@intel.com> <20200403174235.23308-4-konstantin.ananyev@intel.com> In-Reply-To: From: David Marchand Date: Mon, 13 Apr 2020 16:29:30 +0200 Message-ID: To: Honnappa Nagarahalli Cc: "Ananyev, Konstantin" , "dev@dpdk.org" , "jielong.zjl@antfin.com" , nd , "Kinsella, Ray" , Thomas Monjalon , Jerin Jacob Kollanukkaran X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3 3/9] ring: introduce RTS ring mode 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" On Sat, Apr 11, 2020 at 1:10 AM Honnappa Nagarahalli wrote: > > > > > Subject: RE: [PATCH v3 3/9] ring: introduce RTS ring mode > > > > > > Introduce relaxed tail sync (RTS) mode for MT ring synchronization. > > > > Aim to reduce stall times in case when ring is used on overcommited > > > > cpus (multiple active threads on the same cpu). > > > > The main difference from original MP/MC algorithm is that tail valu= e > > > > is increased not by every thread that finished enqueue/dequeue, but > > > > only by the last one. > > > > That allows threads to avoid spinning on ring tail value, leaving > > > > actual tail value change to the last thread in the update queue. > > > > > > > > check-abi.sh reports what I believe is a false-positive about ring > > > > cons/prod changes. As a workaround, devtools/libabigail.abignore is > > > > updated to suppress *struct ring* related errors. > > > This can be removed from the commit message. > > > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > --- > > > > devtools/libabigail.abignore | 7 + > > > > lib/librte_ring/Makefile | 5 +- > > > > lib/librte_ring/meson.build | 5 +- > > > > lib/librte_ring/rte_ring.c | 100 +++++++- > > > > lib/librte_ring/rte_ring.h | 110 ++++++++- > > > > lib/librte_ring/rte_ring_elem.h | 86 ++++++- > > > > lib/librte_ring/rte_ring_rts.h | 316 +++++++++++++++++++++= ++++ > > > > lib/librte_ring/rte_ring_rts_elem.h | 205 ++++++++++++++++ > > > > lib/librte_ring/rte_ring_rts_generic.h | 210 ++++++++++++++++ > > > > 9 files changed, 1015 insertions(+), 29 deletions(-) create mode > > > > 100644 lib/librte_ring/rte_ring_rts.h create mode 100644 > > > > lib/librte_ring/rte_ring_rts_elem.h > > > > create mode 100644 lib/librte_ring/rte_ring_rts_generic.h > > > > > > > > diff --git a/devtools/libabigail.abignore > > > > b/devtools/libabigail.abignore index a59df8f13..cd86d89ca 100644 > > > > --- a/devtools/libabigail.abignore > > > > +++ b/devtools/libabigail.abignore > > > > @@ -11,3 +11,10 @@ > > > > type_kind =3D enum > > > > name =3D rte_crypto_asym_xform_type > > > > changed_enumerators =3D > > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END > > > > +; Ignore updates of ring prod/cons > > > > +[suppress_type] > > > > + type_kind =3D struct > > > > + name =3D rte_ring > > > > +[suppress_type] > > > > + type_kind =3D struct > > > > + name =3D rte_event_ring > > > Does this block the reporting of these structures forever? > > > > Till we'll have a fix in libabigail, then we can remove these lines. > > I don't know any better alternative. > David, does this block all issues in the future for rte_ring library? These two "suppression rules" make libabigail consider as harmless any change on the structures rte_ring and rte_event_ring. With those suppression rules, you won't get any complaint from libabigail (if this is what you call issues :-)). Reviews on those structures must be extra careful, as we are blind with those rules in place. --=20 David Marchand