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 A6E0CA051C; Fri, 17 Jan 2020 18:15:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE2F234EF; Fri, 17 Jan 2020 18:15:23 +0100 (CET) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id D1D072C2B for ; Fri, 17 Jan 2020 18:15:21 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id w15so23514314wru.4 for ; Fri, 17 Jan 2020 09:15:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jqKaK7cGIpE6QziYd+Fc2IAn7x4TXMcz/ihW5wltIak=; b=akrgI66Nqc1FIiMxqBvLbAVDzEM7Sx0ZXOSzPpv3SmZvmUQ38wm+kAR53mMZAK1d05 mO69sKMzZ7i2JIdpzeUSM3EJszJOdcRBrw7BD3N+XpErs4X3HySauI3aTqqVI2HhNtHZ IqS6/3DGM9sTgFEqaMvUAFiyupqIjjG9Yof4mqU3WAK9DB8wHd72z/zrex5zWA9OcSAd CdEJfJabpCXyaRaK75f053oOOruKKxYqSyNkw5+AJZApDfRo4qUAixeEw4YYUnuqqQLY 8gfVVoGk93OLhCT6qV9jF84KNxT+i9WU3r7mhQ+iYkzRrjDbP736ra7CikaGH5qyASSR 4FDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jqKaK7cGIpE6QziYd+Fc2IAn7x4TXMcz/ihW5wltIak=; b=g63r4tzspde8WSKM7PXMr372ctSkZRa0QvCIvZnHBnukaaqjrJsjLd70NrZFmuvUM0 ivOuGlLg8ilrlTmP07VkZsY2rpgWAqNp8uQGkxlKbkkKKrotvCdcw+nCFEIZh7APvG/t Yoi/Xb5YVwflSH6QXryflCEgHTBjZB/DkdKuW7n7O/shQDkOBrpw2coOS8Hq9AjpcAEY OoSgbDNR/pWTgJAXIPDODzZ/r5FafgGkCx3M27NLBHxvWtEk7c5H0wsMV9eTbKit1QDq dRbjsnTWCW8OYpfuBHrur8gHaGDtQYQtVaAOsmHaEG4fWDkESofgildocofznVAR2j/B IWiA== X-Gm-Message-State: APjAAAXSa8Uolx6ESteuOIr6ABd+qio/llZTSdcEdhU8b0yaCw7U1amj p/qPTwnnH1g5hcGtFkHqCHVY2Q== X-Google-Smtp-Source: APXvYqx2tN6W+cni3EHXIiUiSXcFu44uMfGM8TK3JicgCZ/m7Uuk+HNjao+4MBER6zcdsFAkhzHIkA== X-Received: by 2002:a05:6000:1248:: with SMTP id j8mr3961839wrx.44.1579281321487; Fri, 17 Jan 2020 09:15:21 -0800 (PST) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id d8sm35546686wre.13.2020.01.17.09.15.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2020 09:15:20 -0800 (PST) Date: Fri, 17 Jan 2020 18:15:20 +0100 From: Olivier Matz To: Honnappa Nagarahalli Cc: sthemmin@microsoft.com, jerinj@marvell.com, bruce.richardson@intel.com, david.marchand@redhat.com, pbhagavatula@marvell.com, konstantin.ananyev@intel.com, yipeng1.wang@intel.com, dev@dpdk.org, dharmik.thakkar@arm.com, ruifeng.wang@arm.com, gavin.hu@arm.com, nd@arm.com Message-ID: <20200117171520.GB22738@platinum> References: <20190906190510.11146-1-honnappa.nagarahalli@arm.com> <20200116052511.8557-1-honnappa.nagarahalli@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200116052511.8557-1-honnappa.nagarahalli@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH v9 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 Wed, Jan 15, 2020 at 11:25:05PM -0600, 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. > This is a nice improvement to the ring library, thanks! It looks globally good to me, few comments as reply to individual patches. Olivier