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 B7B91A051C; Fri, 17 Jan 2020 22:07:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C1BE73576; Fri, 17 Jan 2020 22:07:28 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 50EAA2C19 for ; Fri, 17 Jan 2020 22:07:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579295245; 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=CvwjHNwS1z07XD4UjPk87G7fCuJrIvhis48iO0nU79g=; b=K++LkKU0wN/v4EeTOM1kUcIBGUyoVUckE+VgjTYzpJT6uzn1qy5gufuX7MkqXTk4FBWUpR SiAcjbzbXwFVzRTA9MBFNSvc4HUYpSE9AZXjQAUDwwC7kTJNMqSkFmyxR6IPhUP2LsnW44 BoMtycObgTguziFy5pVIM1EGRsLA2bo= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-393-dZxVVbFgNOat8SScjfqLuA-1; Fri, 17 Jan 2020 16:07:23 -0500 Received: by mail-vk1-f198.google.com with SMTP id v188so10266701vkf.10 for ; Fri, 17 Jan 2020 13:07:23 -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:content-transfer-encoding; bh=CvwjHNwS1z07XD4UjPk87G7fCuJrIvhis48iO0nU79g=; b=Jw+GRPfnQAaOnin9u0qwUNurF2zqWiXsSsZo9M0HA9rPDZj8fBFDGWQR59hvK5R+KG cGxKmWK8GQ2/jJII5LYv1v1QqtcHmHN3WiGOLOwuHiLLARdts7yMKF6QXtxeIAImb/cJ J8QK7gHTS7T0AKxEdSk44gdg378Re+7bKYfpIunHSK/H4GXkz2c88nHG4+OD7gMFvyef u6+I1Adjp+GTtbfDsqjxsDefEKC5iwTY1Dkn8RNPlGO7fYiVjd9Z0dqlvO45AiHoImx4 4DcsmuHSGk320atCCpLMuwMULpDZx6SfclWlTaMLPXxv59HHuCXAz67Seju+BWRu74uD KXiw== X-Gm-Message-State: APjAAAXa6p+3ELqzfZI6wjSaf0LvA/IlhH/hckeRL89fh77jEsZLeak8 2u4tKM5yzSkNAaRjV4rQ+GjW7QaOKZ2aKh4wvT3y3tTpLWowfmhLHXJjKWSyrD4hyLb+wwpMyN5 gnw9kT874OSsqIj0Erl0= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr6134821vsr.105.1579295243240; Fri, 17 Jan 2020 13:07:23 -0800 (PST) X-Google-Smtp-Source: APXvYqxHEKSr3NfcELJBILdR6aEdfTqa5qXoZXAmhjghL64evepg68Lm8PrUHvRZZ3tZKW+k3LE+zOUGLZs7v+8EEv8= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr6134793vsr.105.1579295242812; Fri, 17 Jan 2020 13:07:22 -0800 (PST) MIME-Version: 1.0 References: <20190906190510.11146-1-honnappa.nagarahalli@arm.com> <20200116052511.8557-1-honnappa.nagarahalli@arm.com> <20200116052511.8557-6-honnappa.nagarahalli@arm.com> In-Reply-To: From: David Marchand Date: Fri, 17 Jan 2020 22:07:11 +0100 Message-ID: To: Honnappa Nagarahalli Cc: Olivier Matz , Stephen Hemminger , "jerinj@marvell.com" , Bruce Richardson , Pavan Nikhilesh , "Ananyev, Konstantin" , "Wang, Yipeng1" , dev , Dharmik Thakkar , Ruifeng Wang , Gavin Hu , nd , "thomas@monjalon.net" X-MC-Unique: dZxVVbFgNOat8SScjfqLuA-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 v9 5/6] lib/hash: use ring with 32b element size to save memory 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, Jan 17, 2020 at 9:54 PM Honnappa Nagarahalli wrote: > > > > > > > On Thu, Jan 16, 2020 at 6:25 AM Honnappa Nagarahalli > > wrote: > > > > > > The freelist and external bucket indices are 32b. Using rings that us= e > > > 32b element sizes will save memory. > > > > > > Signed-off-by: Honnappa Nagarahalli > > > Reviewed-by: Gavin Hu > > > Reviewed-by: Ola Liljedahl > > > --- > > > lib/librte_hash/rte_cuckoo_hash.c | 94 > > > ++++++++++++++++--------------- lib/librte_hash/rte_cuckoo_hash.h | > > > 2 +- > > > 2 files changed, 50 insertions(+), 46 deletions(-) > > > > > > > [snip] > > > > > diff --git a/lib/librte_hash/rte_cuckoo_hash.h > > > b/lib/librte_hash/rte_cuckoo_hash.h > > > index fb19bb27d..345de6bf9 100644 > > > --- a/lib/librte_hash/rte_cuckoo_hash.h > > > +++ b/lib/librte_hash/rte_cuckoo_hash.h > > > @@ -124,7 +124,7 @@ const rte_hash_cmp_eq_t > > > cmp_jump_table[NUM_KEY_CMP_CASES] =3D { > > > > > > struct lcore_cache { > > > unsigned len; /**< Cache len */ > > > - void *objs[LCORE_CACHE_SIZE]; /**< Cache objects */ > > > + uint32_t objs[LCORE_CACHE_SIZE]; /**< Cache objects */ > > > > This triggers a warning in ABI checks: > > > > 1 function with some indirect sub-type change: > > > > [C]'function int32_t rte_hash_add_key(const rte_hash*, void*)' at > > rte_cuckoo_hash.c:1118:1 has some indirect sub-type changes: > > parameter 1 of type 'const rte_hash*' has sub-type changes: > > in pointed to type 'const rte_hash': > > in unqualified underlying type 'struct rte_hash' at > > rte_cuckoo_hash.h:160:1: > > type size hasn't changed > > 1 data member change: > > type of 'lcore_cache* rte_hash::local_free_slots' changed: > > in pointed to type 'struct lcore_cache' at rte_cuckoo_hash= .h:125:1: > > type size changed from 4608 to 2560 (in bits) > > 1 data member change: > > type of 'void* lcore_cache::objs[64]' changed: > > array element type 'void*' changed: > > entity changed from 'void*' to 'typedef uint32_t' > > at stdint-uintn.h:26:1 > > type size changed from 64 to 32 (in bits) > > type name changed from 'void*[64]' to 'uint32_t[64]' > > array type size changed from 4096 to 2048 > > and offset changed from 64 to 32 (in bits) (by -32 bits= ) > > > > As far as I can see, the local_free_slots field in rte_hash is supposed= to be > > internal and should just be hidden from users. > > lib/librte_hash/rte_cuckoo_hash.c: h->local_free_slots =3D > > rte_zmalloc_socket(NULL, > > lib/librte_hash/rte_cuckoo_hash.c: rte_free(h->local_free_= slots); > > lib/librte_hash/rte_cuckoo_hash.c: cached_cnt +=3D > > h->local_free_slots[i].len; > > lib/librte_hash/rte_cuckoo_hash.c: > > h->local_free_slots[i].len =3D 0; > > lib/librte_hash/rte_cuckoo_hash.c: cached_free_slots =3D > > &h->local_free_slots[lcore_id]; > > lib/librte_hash/rte_cuckoo_hash.c: cached_free_slots =3D > > &h->local_free_slots[lcore_id]; > > lib/librte_hash/rte_cuckoo_hash.c: cached_free_slots =3D > > &h->local_free_slots[lcore_id]; > > lib/librte_hash/rte_cuckoo_hash.h: struct lcore_cache *local_free_= slots; > > > > Not sure how users could make use of this. > > But the abi check flags this as a breakage since this type was exported= . > I think this is a false positive. > > Users include 'rte_hash.h' file which does not define the structure. It j= ust has the declaration 'struct rte_hash'. The actual structure is defined = in 'rte_cuckoo_hash.h'. But this is not included by the user. So, the appli= cation does not have visibility into 'struct rte_hash' as defined in 'rte_c= uckoo_hash.h'. > > The 'rte_create_hash' API returns a pointer to the 'struct rte_hash'. All= the APIs are non-inline and just take this pointer as the argument. So, th= e 'struct rte_hash' as defined in 'rte_cuckoo_hash.h' is not used by the us= er. Indeed, it seems properly hidden. Scratching the rest of the mail. Looked at abidiff, I can see it takes a public headers directory to filter the ABI changes. Need to make this work. --=20 David Marchand