From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by dpdk.org (Postfix) with ESMTP id 062D72B97 for ; Thu, 3 Mar 2016 04:36:01 +0100 (CET) Received: by mail-qg0-f46.google.com with SMTP id t4so8060849qge.0 for ; Wed, 02 Mar 2016 19:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=XN0oVMx6DXoYgBlSUE7Fsy0dohPNvQVkVn+bdsB5BUA=; b=RVbIsa0xcQGgL/XJT+r2GxL/FHWvoTuB4PGIfrluOlZN3ivEVjvXp6axq4YUYoH324 L/Ym5hB2nnCnMmVcZc+YC+7k9Vy3a+ssvnMBF7fUlvk7eaddixdWmNsQ60LRWODiz8c4 1LVbkjgyD9Ly2cgLXdK0PkvAnW4iRW/eznPWKZncAzqT0EzzWoSIaAmDQ2lFGVJBqaqp gPFXvHZe0DAwDvBXrmjldpHrcMt9oLx44cCXo1aS6G92K8vdzw9bp0ve2ztIMt6pbW1Y /4Nuqym3m9uOeSv7Om7ghFDkzxu0+B60E0PBLHjl/LG9Mcw8XQfoe8EF4zg1Schw62b/ zexA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=XN0oVMx6DXoYgBlSUE7Fsy0dohPNvQVkVn+bdsB5BUA=; b=HcI9By+fzl1a8o5axlgM8xRNLISWT+Y/sGkB3B8LlVkYTWISrdBjDz42mzrzuuAGEH Uadh9wwXeExNEO15b5c28my/1O0ryAbJc0EaMyYNeVeeFJUd1tDXZO3Uq8wfei0UDyRn /xcriyEUQh7YcM9AISnCmTy4fLMsBYHSKkLHXbZnUkdP7LFUhX51Ob5EttPwb11e2tnp 0wKHZW0Ew6/HglgmmtP4hLNL3f5xT/C3aMVLFmgYYDMTwOX6ncZMNUhEByECXrLTgUjJ Ye+2NLNnupdgXygO8OgEkmWhBZUTNTyP8OdcpmP17/QzmlxtAQW4Glvy02S5+jhM+D5+ 2Igg== X-Gm-Message-State: AD7BkJIg95NzHEPLH0qGLVMyECCFwKNpy/YLGN/QsApFIseQU6NVspTFdPss0OkkQp/KCQ== X-Received: by 10.140.171.7 with SMTP id r7mr375890qhr.79.1456976160521; Wed, 02 Mar 2016 19:36:00 -0800 (PST) Received: from abhi.mysweetnetwork.com (c-76-119-251-132.hsd1.ma.comcast.net. [76.119.251.132]) by smtp.gmail.com with ESMTPSA id w188sm13060483qhb.37.2016.03.02.19.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2016 19:36:00 -0800 (PST) From: Dhana Eadala To: bruce.richardson@intel.com, pablo.de.lara.guarch@intel.com, michael.qiu@intel.com Date: Wed, 2 Mar 2016 22:35:52 -0500 Message-Id: <1456976152-15640-1-git-send-email-edreddy@gmail.com> X-Mailer: git-send-email 2.5.0 Cc: dev@dpdk.org Subject: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment 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, 03 Mar 2016 03:36:01 -0000 We found a problem in dpdk-2.2 using under multi-process environment. Here is the brief description how we are using the dpdk: We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are two different compiled binaries. proc1 is started as primary process and proc2 as secondary process. proc1: Calls srcHash = rte_hash_create("src_hash_name") to create rte_hash structure. As part of this, this api initalized the rte_hash structure and set the srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1 address space. proc2: calls srcHash = rte_hash_find_existing("src_hash_name"). This returns the rte_hash created by proc1. This srcHash->rte_hash_cmp_eq still points to the address of memcmp() from proc1 address space. Later proc2 calls rte_hash_lookup_with_hash(srcHash, (const void*) &key, key.sig); Under the hood, rte_hash_lookup_with_hash() invokes __rte_hash_lookup_with_hash(), which in turn calls h->rte_hash_cmp_eq(key, k->key, h->key_len). This leads to a crash as h->rte_hash_cmp_eq is an address from proc1 address space and is invalid address in proc2 address space. We found, from dpdk documentation, that " The use of function pointers between multiple processes running based of different compiled binaries is not supported, since the location of a given function in one process may be different to its location in a second. This prevents the librte_hash library from behaving properly as in a multi- threaded instance, since it uses a pointer to the hash function internally. To work around this issue, it is recommended that multi-process applications perform the hash calculations by directly calling the hashing function from the code and then using the rte_hash_add_with_hash()/rte_hash_lookup_with_hash() functions instead of the functions which do the hashing internally, such as rte_hash_add()/rte_hash_lookup(). " We did follow the recommended steps by invoking rte_hash_lookup_with_hash(). It was no issue up to and including dpdk-2.0. In later releases started crashing because rte_hash_cmp_eq is introduced in dpdk-2.1 We fixed it with the following patch and would like to submit the patch to dpdk.org. Patch is created such that, if anyone wanted to use dpdk in multi-process environment with function pointers not shared, they need to define RTE_LIB_MP_NO_FUNC_PTR in their Makefile. Without defining this flag in Makefile, it works as it is now. Signed-off-by: Dhana Eadala --- lib/librte_hash/rte_cuckoo_hash.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c index 3e3167c..0946777 100644 --- a/lib/librte_hash/rte_cuckoo_hash.c +++ b/lib/librte_hash/rte_cuckoo_hash.c @@ -594,7 +594,11 @@ __rte_hash_add_key_with_hash(const struct rte_hash *h, const void *key, prim_bkt->signatures[i].alt == alt_hash) { k = (struct rte_hash_key *) ((char *)keys + prim_bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp(key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif /* Enqueue index of free slot back in the ring. */ enqueue_slot_back(h, cached_free_slots, slot_id); /* Update data */ @@ -614,7 +618,11 @@ __rte_hash_add_key_with_hash(const struct rte_hash *h, const void *key, sec_bkt->signatures[i].current == alt_hash) { k = (struct rte_hash_key *) ((char *)keys + sec_bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp(key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif /* Enqueue index of free slot back in the ring. */ enqueue_slot_back(h, cached_free_slots, slot_id); /* Update data */ @@ -725,7 +733,11 @@ __rte_hash_lookup_with_hash(const struct rte_hash *h, const void *key, bkt->signatures[i].sig != NULL_SIGNATURE) { k = (struct rte_hash_key *) ((char *)keys + bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp (key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif if (data != NULL) *data = k->pdata; /* @@ -748,7 +760,11 @@ __rte_hash_lookup_with_hash(const struct rte_hash *h, const void *key, bkt->signatures[i].alt == sig) { k = (struct rte_hash_key *) ((char *)keys + bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp(key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif if (data != NULL) *data = k->pdata; /* @@ -840,7 +856,11 @@ __rte_hash_del_key_with_hash(const struct rte_hash *h, const void *key, bkt->signatures[i].sig != NULL_SIGNATURE) { k = (struct rte_hash_key *) ((char *)keys + bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp(key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif remove_entry(h, bkt, i); /* @@ -863,7 +883,11 @@ __rte_hash_del_key_with_hash(const struct rte_hash *h, const void *key, bkt->signatures[i].sig != NULL_SIGNATURE) { k = (struct rte_hash_key *) ((char *)keys + bkt->key_idx[i] * h->key_entry_size); +#ifdef RTE_LIB_MP_NO_FUNC_PTR + if (memcmp(key, k->key, h->key_len) == 0) { +#else if (h->rte_hash_cmp_eq(key, k->key, h->key_len) == 0) { +#endif remove_entry(h, bkt, i); /* @@ -980,7 +1004,11 @@ lookup_stage3(unsigned idx, const struct rte_hash_key *key_slot, const void * co unsigned hit; unsigned key_idx; +#ifdef RTE_LIB_MP_NO_FUNC_PTR + hit = !memcmp(key_slot->key, keys[idx], h->key_len); +#else hit = !h->rte_hash_cmp_eq(key_slot->key, keys[idx], h->key_len); +#endif if (data != NULL) data[idx] = key_slot->pdata; -- 2.5.0