From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.189.228]) by dpdk.org (Postfix) with ESMTP id 2720CB3AD for ; Thu, 25 Sep 2014 09:40:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1411631190; x=1443167190; h=from:to:subject:date:message-id:mime-version; bh=iVPVVzXsTWkCVe/6OPy4C/aM7tRCcuil170bnpUJlOE=; b=Anq67js8RaULZX2SvHsZcfLYCEEW8lmiPUYM5LbHH6isiIo/ObOvw8XR N1xXCiNdzU/e7/4XL2mm9Vjz4om8ZqZaMTDykiO1wS3oBwbDPKA11YBxR Si6cilS6ltgpfj4w65KT6xKoGEyJ0GpbqJovQrVPOQjg+cTfRPv3FGJ+q A=; X-IronPort-AV: E=Sophos;i="5.04,595,1406592000"; d="scan'208,217";a="106833076" Received: from email-inbound-relay-62001.pdx2.amazon.com ([10.241.21.123]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Sep 2014 07:46:25 +0000 Received: from ex10-hub-9004.ant.amazon.com (pdx2-ws-svc-lb17-vlan2.amazon.com [10.247.140.66]) by email-inbound-relay-62001.pdx2.amazon.com (8.14.7/8.14.7) with ESMTP id s8P7kOPX001036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 25 Sep 2014 07:46:24 GMT Received: from EX10-MBX-9001.ant.amazon.com ([fe80::1023:3a45:4674:52c6]) by ex10-hub-9004.ant.amazon.com ([::1]) with mapi id 14.03.0181.006; Thu, 25 Sep 2014 00:46:17 -0700 From: "Saha, Avik (AWS)" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] Fix for LRU corrupted returns Thread-Index: Ac/Yk7ywkHZ3u5mETg2SYiggoS84qQ== Date: Thu, 25 Sep 2014 07:46:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.49.70] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [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: Thu, 25 Sep 2014 07:40:14 -0000 This is a patch to a problem that I have faced (described in the thread) a= nd this works for me. 1) Since the data_size_shl was getting its value from the key_size, th= e table data entries were being corrupted when the calculation to shift the= number of bits was being made based on the key_size (according to the docu= ment the key_size and entry_size are independently configurable) - With thi= s fix, we get the MSB that is set in entry_size (also removes the constrain= t of this having to be a power of 2 - not entirely sure if this was the rea= son the constraint was kept though) 2) The document does not say that the entry_size needs to be a power o= f 2 and this was failing silently when I was trying to bring my application= up. diff --git a/DPDK/lib/librte_table/rte_table_hash_lru.c b/DPDK/lib/librte_t= able/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_id,= uint32_t entry_size) uint32_t i; /* 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 the + // Programmers Guide does not call this out and we are going to han= dle + // the data_size_shl of the table later on (Line 197) + 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)); /* Tables */ table_meta_offset =3D 0; -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Saha, Avik (AWS) Sent: Wednesday, September 24, 2014 4:12 PM To: dev@dpdk.org Subject: [dpdk-dev] Strange behaviour with LRU table 1) All the calls to add entries succeeds 2) The key look up works as expected. 3) The value (entry_data) that is returned is incorrect for every othe= r entry - 1st entry data on .f_action_hit is wrong, 2nd entry_data on .f_a= ction_hit is correct and so on. I have initialized my LRU as follows: struct rte_pipeline_table_params table_params =3D { .ops =3D &rte_table_hash_lru_dosig_ops, .arg_create =3D &rule_tbl_params, .f_action_hit =3D rw_pipeline_stage_2_cache_hit, .f_action_miss =3D rw_pipeline_stage_2_cache_miss, .arg_ah =3D (void *)lcore_params, .action_data_size =3D 16, }; Is there something obvious I am missing - from first look it seems to be a = problem with cache lines but I really am not sure. Avik