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 8755AA0520; Sun, 19 Jan 2020 20:32:14 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2CD691E34; Sun, 19 Jan 2020 20:32:13 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id E9E0A1DBA for ; Sun, 19 Jan 2020 20:32:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579462331; 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=Zkt2XCAJWRVPSHtWStrZhRdB2Dko3uikjsS476DJA1M=; b=Nbf3hsWIplSwoTBynOmoQdrLdu9nW+zwfojo5fLtkKga4r9nHE6VHv1U8lS0ZI6kAoYG5N IA+CHQInA4IfZxs3DU+hoFzMb+jog96pVt+gvFboceYHsDTfP8z5Zzv8u2bq7NzhoJjjbt g+RFCX+TqcrN3tCRyJyBFMNpCZMQ6rY= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-18-JsH-o7xmObWVsAKvF2EeJA-1; Sun, 19 Jan 2020 14:32:06 -0500 Received: by mail-vs1-f69.google.com with SMTP id l1so2798968vsr.21 for ; Sun, 19 Jan 2020 11:32:06 -0800 (PST) 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=Zkt2XCAJWRVPSHtWStrZhRdB2Dko3uikjsS476DJA1M=; b=d54sfRq8hY1AmGAuCHo2oFuWzJP7d8ZxVm39X6TN4O9eh2rCWaMM6KZhM6jljmok8H w79byYxr5lfAk71SpKzWENtBvggUbYX1pqugP+TlEnP9B3jqQ3GdlT5CF72ZrIDvPX7J HUt+6UNoefUWiie95rSfcvgU0Qu61faGyXlnkp3WabX/v02OLF/QFOoB+Hf0sBX4NxUG fvukQwxGCOttbpnXrxEmy81C6kwZDYEE+WteXK3ISilVz1odaf5o8nUqhfjC7Ol/Vu1G 6Iu3OrPmKseyqLSOvwXq2tsIabieUiIb03256VPfaG9BOwdM9XxyBjujn8DEKtoCzoK2 nCow== X-Gm-Message-State: APjAAAVgBhWKx1U1OLBmgggJ2AwLX10fmDadoUbVI43j+pfAT5aoJdvH X/nD8osH2tXm8hfsytdNxNCT4lwSuW8G32N/SrzIDQg5bppV442PrENFXJ5Ee1pDJC5Vzdp/+uq +TEdRHibsmd1tO7/smpg= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr11049028vsm.180.1579462326295; Sun, 19 Jan 2020 11:32:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwEm8ihXugEHJPesQvWUMX28FEYH0YWe1Cslg7DKdHupvBTHMEuTizYDwNmzNj3JRBrAXlSUCgiVJmyVmo2BWE= X-Received: by 2002:a67:f1ca:: with SMTP id v10mr11049001vsm.180.1579462325957; Sun, 19 Jan 2020 11:32:05 -0800 (PST) MIME-Version: 1.0 References: <20190906190510.11146-1-honnappa.nagarahalli@arm.com> <20200118193247.43831-1-honnappa.nagarahalli@arm.com> In-Reply-To: <20200118193247.43831-1-honnappa.nagarahalli@arm.com> From: David Marchand Date: Sun, 19 Jan 2020 20:31:54 +0100 Message-ID: To: Honnappa Nagarahalli Cc: Olivier Matz , Stephen Hemminger , Jerin Jacob Kollanukkaran , Bruce Richardson , Pavan Nikhilesh , "Ananyev, Konstantin" , "Wang, Yipeng1" , David Christensen , dev , Dharmik Thakkar , "Ruifeng Wang (Arm Technology China)" , Gavin Hu , nd X-MC-Unique: JsH-o7xmObWVsAKvF2EeJA-1 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 v10 0/6] lib/ring: APIs to support custom element size 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, Jan 18, 2020 at 8:33 PM Honnappa Nagarahalli wrote: > > The current rte_ring hard-codes the type of the ring element to 'void *', > hence the size of the element is hard-coded to 32b/64b. Since the ring > element type is not an input to rte_ring APIs, it results in couple > of issues: > > 1) If an application requires to store an element which is not 64b, it > needs to write its own ring APIs similar to rte_event_ring APIs. This > creates additional burden on the programmers, who end up making > work-arounds and often waste memory. > 2) If there are multiple libraries that store elements of the same > type, currently they would have to write their own rte_ring APIs. This > results in code duplication. > > This patch adds new APIs to support configurable ring element size. > The APIs support custom element sizes by allowing to define the ring > element to be a multiple of 32b. > > The aim is to achieve same performance as the existing ring > implementation. > > v10 > - Improved comments in test case files (Olivier) > - Fixed possible memory leaks (Olivier) > - Changed 'test_ring_with_exact_size' to use unaligned > addresses (Konstantin) > - Changed the commit message for eventdev (Jerin) Thanks for working on this and a big thanks to all reviewers too. The CI has been switched to Ubuntu 18.04, so that we won't hit the Travis timeout with clang 7. There is still some work on the ABI checks, because of the abidiff report on rte_cuckoo_hash.h I mentioned: passing the public headers to abidw/abidiff should do the trick. Series applied. -- David Marchand