From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) by dpdk.org (Postfix) with ESMTP id 216FD6A89 for ; Tue, 30 Sep 2014 08:19:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1412058387; x=1443594387; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MrUYWhuCYmBZ4bY67N63djApis28KMcIQHMGiKfzLYQ=; b=UFdS5KTaZuOyTbQQor14Kmqil7QZZcX76/qRoTqaFp+Bs9qPGQ5sVqEl fTlr7d8J3+aW9XFlyGR9LejzayUvhUbxO63riPzkphnzhKv3Oe5L4E1Pr 2Vxz254JY8NIckFo7JSAQ92uVa153lC4Ug8989PSVGanqQKGUui8kAGaa w=; X-IronPort-AV: E=Sophos;i="5.04,625,1406592000"; d="scan'208";a="149385693" Received: from email-inbound-relay-62002.pdx2.amazon.com ([10.241.21.79]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Sep 2014 06:26:25 +0000 Received: from ex10-hub-31002.ant.amazon.com (pdx2-ws-svc-lb17-vlan2.amazon.com [10.247.140.66]) by email-inbound-relay-62002.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id s8U6QOhm032709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 30 Sep 2014 06:26:25 GMT Received: from EX10-MBX-31003.ant.amazon.com ([fe80::5833:b3e6:f957:e42a]) by ex10-hub-31002.ant.amazon.com ([::1]) with mapi id 14.03.0181.006; Mon, 29 Sep 2014 23:26:24 -0700 From: "Saha, Avik (AWS)" To: Neil Horman Thread-Topic: [dpdk-dev] [PATCH] Fix for LRU corrupted returns Thread-Index: AQHP2KqLB1I3H3BZREmu6z+y0SVEIpwZPMLQ Date: Tue, 30 Sep 2014 06:26:23 +0000 Message-ID: References: <20140925102155.GB32725@hmsreliant.think-freely.org> In-Reply-To: <20140925102155.GB32725@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] Fix for LRU corrupted returns X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:19:48 -0000 Sorry about the delay. The number 32 is not really a CACHE_LINE_SIZE but si= nce __builtin_clz returns the number of leading 0's before the most signifi= cant set bit in a 32 bit number (entry_size is uint32_t), I subtract that n= umber from 32 to get the number of trailing bits after the most significant= set bit. This will be the separation in my data_mem regions. -----Original Message----- From: Neil Horman [mailto:nhorman@tuxdriver.com]=20 Sent: Thursday, September 25, 2014 3:22 AM To: Saha, Avik (AWS) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] Fix for LRU corrupted returns On Thu, Sep 25, 2014 at 07:46:16AM +0000, Saha, Avik (AWS) wrote: > This is a patch to a problem that I have faced (described in the thread)= and this works for me. >=20 > 1) Since the data_size_shl was getting its value from the key_size, = the table data entries were being corrupted when the calculation to shift t= he number of bits was being made based on the key_size (according to the do= cument the key_size and entry_size are independently configurable) - With t= his fix, we get the MSB that is set in entry_size (also removes the constra= int of this having to be a power of 2 - not entirely sure if this was the r= eason the constraint was kept though) > 2) The document does not say that the entry_size needs to be a power= of 2 and this was failing silently when I was trying to bring my applicati= on up. >=20 > diff --git a/DPDK/lib/librte_table/rte_table_hash_lru.c=20 > b/DPDK/lib/librte_table/rte_table_hash_lru.c > index d1a4984..4ec9aa4 100644 > --- a/DPDK/lib/librte_table/rte_table_hash_lru.c > +++ b/DPDK/lib/librte_table/rte_table_hash_lru.c > @@ -153,8 +153,10 @@ rte_table_hash_lru_create(void *params, int socket_i= d, uint32_t entry_size) > uint32_t i; >=20 > /* Check input parameters */ > - if ((check_params_create(p) !=3D 0) || > - (!rte_is_power_of_2(entry_size)) || > + // Commenting out the power of 2 check on the entry_size since th= e > + // Programmers Guide does not call this out and we are going to h= andle > + // the data_size_shl of the table later on (Line 197) Please remove the reference to Line 197 here. Thats not going to remain ac= curate for very long. > + if ((check_params_create(p) !=3D 0) || > ((sizeof(struct rte_table_hash) % CACHE_LINE_SIZE) !=3D 0= ) || > (sizeof(struct bucket) !=3D (CACHE_LINE_SIZE / 2))) { > return NULL; > @@ -192,7 +194,7 @@ rte_table_hash_lru_create(void *params, int socket_id= , uint32_t entry_size) > /* Internal */ > t->bucket_mask =3D t->n_buckets - 1; > t->key_size_shl =3D __builtin_ctzl(p->key_size); > - t->data_size_shl =3D __builtin_ctzl(p->key_size); > + t->data_size_shl =3D 32 - (__builtin_clz(entry_size)); I presume the 32 value here is a cache line size? That should be replaced = with CACHE_LINE_SIZE...Though looking at it, that doesn't seem sufficient. = Seems like we need a eal abstraction to dynamically tell us what the cache= line size is (we can read it from /proc/cpuinfo in linux, not sure about b= sd). Neil