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 36328A2EEB for ; Mon, 7 Oct 2019 15:49:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 34FEE1C1E9; Mon, 7 Oct 2019 15:49:57 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 88D6D1C1A3 for ; Mon, 7 Oct 2019 15:49:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1570456195; 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=wqpqQ8YmSARN+4eeo1cI8sTCHizJUbVb0/bANnsjES0=; b=Qb4LPi9KTW21Z872sUDU/h8/zu5gpDJvMb4PRiK1jG/MVTFvHkTSlSldX6YxaTStfNc3Sm UU03QwaOtJIdzX6OWg2KlMv5f8xRjr1wJ32h6D4CtVm/hjZS+hnyMymhIzRbx6vTe4P3nD qRfVYn5SHynkJhaymzboJWs7+HXCv7o= Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-203-gDi6yo9xOoOr0RjcsS5fIw-1; Mon, 07 Oct 2019 09:49:53 -0400 Received: by mail-vk1-f197.google.com with SMTP id b204so6834176vkb.11 for ; Mon, 07 Oct 2019 06:49:53 -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=stEVj4JwsCDCiwDKxvragOS2RDwVB8m7e6VZ7949qhs=; b=XkxWR/xEhAyj0Jr/j3NrRZxW6I7Rrvi+o5reRPsCcKfHMbtbyvl9OOpNNznr7qsWne HL2RvFe9Q4BlhZNmnJ1zM1EelbxhMJGZ1BgFo+yrs+z8Uhp5DBUool22FH2u7v9ZRoIK ORNwNqHq0aZg3SZfTinitdkP+FFSJgfGvqfbIQB5ytUuWnEBxRRz0OqLYi1rf/LzVeG2 hMUHyeYhDE8ho2/CXOvs1c2bNZlWKvwocMvZkAS3EspBLZKUSkDMOhoGYzewKvbCMTDG Bpg7y1qirRcUQKBZlm5Kro3lml4N+tguO7jujBpitKhzhtDkkSy3ITuzRUlvYKgE6v78 i8tA== X-Gm-Message-State: APjAAAXSFcgASlkZ1RVNc2WH1/T1RobCtcYryblIZwL64cOMKh5hZ531 vRvOqYOKUEkfmaHO1+9Wp3+l//K78qhoGXMjqp8V4eBfsxkM7MH84HaSwSPmkiAeAecewnZbl2P P5J3PdFeWKnsQHWvzB4Q= X-Received: by 2002:ac5:c911:: with SMTP id t17mr4631796vkl.56.1570456192927; Mon, 07 Oct 2019 06:49:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqzU5PYRE5v4cwoeuTM6ud0+CfmVeE2cqIJMz7OsfOpwQnGLyxc6xTjO2giiejyIxIumXRuAqBeulvEAKTFbKr4= X-Received: by 2002:ac5:c911:: with SMTP id t17mr4631782vkl.56.1570456192476; Mon, 07 Oct 2019 06:49:52 -0700 (PDT) MIME-Version: 1.0 References: <20190828144614.25284-1-honnappa.nagarahalli@arm.com> <20190906190510.11146-1-honnappa.nagarahalli@arm.com> In-Reply-To: <20190906190510.11146-1-honnappa.nagarahalli@arm.com> From: David Marchand Date: Mon, 7 Oct 2019 15:49:41 +0200 Message-ID: To: Honnappa Nagarahalli Cc: Olivier Matz , "Wang, Yipeng1" , "Gobriel, Sameh" , Bruce Richardson , Pablo de Lara , dev , pbhagavatula@marvell.com, Jerin Jacob Kollanukkaran X-MC-Unique: gDi6yo9xOoOr0RjcsS5fIw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2 0/6] lib/ring: templates 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 Fri, Sep 6, 2019 at 9:05 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 consists of several parts: > 1) New APIs to support configurable ring element size > These will help reduce code duplication in the templates. I think thes= e > can be made internal (do not expose to DPDK applications, but expose t= o > DPDK libraries), feedback needed. > > 2) rte_ring templates > The templates provide an easy way to add new APIs for different ring > element types/sizes which can be used by multiple libraries. These > also allow for creating APIs to store elements of custom types > (for ex: a structure) > > The template needs 4 parameters: > a) RTE_RING_TMPLT_API_SUFFIX - This is used as a suffix to the > rte_ring APIs. > For ex: if RTE_RING_TMPLT_API_SUFFIX is '32b', the API name will be > rte_ring_create_32b > b) RTE_RING_TMPLT_ELEM_SIZE - Size of the ring element in bytes. > For ex: sizeof(uint32_t) > c) RTE_RING_TMPLT_ELEM_TYPE - Type of the ring element. > For ex: uint32_t. If a common ring library does not use a standard > data type, it should create its own type by defining a structure > with standard data type. For ex: for an elment size of 96b, one > could define a structure > > struct s_96b { > uint32_t a[3]; > } > The common library can use this structure to define > RTE_RING_TMPLT_ELEM_TYPE. > > The application using this common ring library should define its > element type as a union with the above structure. > > union app_element_type { > struct s_96b v; > struct app_element { > uint16_t a; > uint16_t b; > uint32_t c; > uint32_t d; > } > } > d) RTE_RING_TMPLT_EXPERIMENTAL - Indicates if the new APIs being defin= ed > are experimental. Should be set to empty to remove the experimental > tag. > > The ring library consists of some APIs that are defined as inline > functions and some APIs that are non-inline functions. The non-inline > functions are in rte_ring_template.c. However, this file needs to be > included in other .c files. Any feedback on how to handle this is > appreciated. > > Note that the templates help create the APIs that are dependent on the > element size (for ex: rte_ring_create, enqueue/dequeue etc). Other API= s > that do NOT depend on the element size do not need to be part of the > template (for ex: rte_ring_dump, rte_ring_count, rte_ring_free_count > etc). > > 3) APIs for 32b ring element size > This uses the templates to create APIs to enqueue/dequeue elements of > size 32b. > > 4) rte_hash libray is changed to use 32b ring APIs > The 32b APIs are used in rte_hash library to store the free slot index > and free bucket index. > > 5) Event Dev changed to use ring templates > Event Dev defines its own 128b ring APIs using the templates. This hel= ps > in keeping the 'struct rte_event' as is. If Event Dev has to use gener= ic > 128b ring APIs, it requires 'struct rte_event' to change to > 'union rte_event' to include a generic data type such as '__int128_t'. > This breaks the API compatibility and results in large number of > changes. > With this change, the event rings are stored on rte_ring's tailq. > Event Dev specific ring list is NOT available. IMO, this does not have > any impact to the user. > > This patch results in following checkpatch issue: > WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' > > However, this patch is following the rules in the existing code. Please > let me know if this needs to be fixed. > > v2 > - Change Event Ring implementation to use ring templates > (Jerin, Pavan) I expect a v3 on this series: - Bruce/Stephen were not happy with using macros, - Aaron caught test issues, - from my side, if patch 3 still applies after your changes, I prefer we drop this patch on the check script, we can live with these warnings, Thanks. --=20 David Marchand