From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id BC8082BB2 for ; Tue, 22 Mar 2016 12:43:51 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id l68so148413759wml.0 for ; Tue, 22 Mar 2016 04:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=KFb9kxqVDwdxpNUMJBgaPNgHbWo6kMqXjjhjLzUXQ+M=; b=SIMP3RVaAiSyJkJvZ+syNx1VuVQPQk6cWfSbD1vM1oPAK1lYWPXPFLccOnSXURFoqF LOhmGRciyGrltNx3h4fgmX7gaC1YzdxbF/b7bWWyZ3OI4zw+f+uhaSraIAJXtsB3fBXB T/wacshjeDwUqW4ShX4M53xl/Y+05NRm7vAwL7rPClSgkUSv/WLp1k4Cq416RO9LeIkp OehZWZRpDyG7PZnNEgO2H3NIo2UkmuYCSG3tkl6Ghmf9RZ/RSpbvQJAD23qP/rVK+Zv9 D0VUyytaf4u56J7tymt0M2beAin9PXPZPsO1ZFyuFym4PMDyTe5Mq1PLzswSZgMqffND leOQ== 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:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=KFb9kxqVDwdxpNUMJBgaPNgHbWo6kMqXjjhjLzUXQ+M=; b=CApCtdgUQWIb2Z4fEcRqp5q7peJt/WDXx+5mBBlbt5Au9uCrVABKbCg0kqDKiCvw56 1PmsPStakJHMfWXop7wuuQ2AiTP3KUNaITtcMS6PbPR0FAdAF+JocD86dFvL9g0eJ7DB qkenF9LCErhrpGkRCHCaj6seTX7mC7zitGw1SU6w/tmRGFXEK94WmTSaDcmr6SI3IBLE QiZCNu6quHStcs8wwFQAuWwA28IwK/p5mRfzf9xxTOKryAMbevj/lATeeAU0KSkAw5Id /tAN/UqBwicncc0BxotFY20hNE1HyF+aPl4RprZ5hbBWKF7Gm+110b65824RpjMFYLbV 6DBg== X-Gm-Message-State: AD7BkJJtEzEDKLlFAfg7xoLF2qYCc2n1YF6ykuWqbC7WgVVwBv5sST2jCU81YVky6RJWjEvs X-Received: by 10.194.62.179 with SMTP id z19mr37707094wjr.96.1458647031602; Tue, 22 Mar 2016 04:43:51 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id w15sm16918336wmd.10.2016.03.22.04.43.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 04:43:50 -0700 (PDT) From: Thomas Monjalon To: pablo.de.lara.guarch@intel.com, sergio.gonzalez.monroy@intel.com Cc: dev@dpdk.org, Dhana Eadala , bruce.richardson@intel.com, michael.qiu@intel.com Date: Tue, 22 Mar 2016 12:42:11 +0100 Message-ID: <76801321.W6WWktetkp@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1457921808-14261-1-git-send-email-edreddy@gmail.com> References: <1457921808-14261-1-git-send-email-edreddy@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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: Tue, 22 Mar 2016 11:43:51 -0000 Hi, Pablo, Sergio, please could you help with this issue? 2016-03-13 22:16, Dhana Eadala: > 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 function call 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); > 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. Introducing #ifdef RTE_LIB_MP_NO_FUNC_PTR is not recommended.