From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 2E2AEA255 for ; Wed, 2 Mar 2016 03:32:32 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 01 Mar 2016 18:32:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,526,1449561600"; d="scan'208";a="756399726" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 01 Mar 2016 18:32:31 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 1 Mar 2016 18:31:56 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.24]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 10:29:49 +0800 From: "Qiu, Michael" To: Dhananjaya Reddy Eadala , "Richardson, Bruce" , "De Lara Guarch, Pablo" Thread-Topic: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process Thread-Index: AQHRc+wxxF9RJ1mdr0C97zAg3Xzv2Q== Date: Wed, 2 Mar 2016 02:29:48 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E6028622F5ACB9@SHSMSX101.ccr.corp.intel.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] 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] hash: fix memcmp function pointer in multi-process 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: Wed, 02 Mar 2016 02:32:32 -0000 On 3/2/2016 2:57 AM, Dhananjaya Reddy Eadala wrote:=0A= > Hi=0A= >=0A= > We found a problem in dpdk-2.2 using under multi-process environment.=0A= > Here is the brief description how we are using the dpdk:=0A= >=0A= > We have two processes proc1, proc2 using dpdk. These proc1 and proc2 are= =0A= > two different compiled binaries.=0A= > proc1 is started as primary process and proc2 as secondary process.=0A= >=0A= > proc1:=0A= > Calls srcHash =3D rte_hash_create("src_hash_name") to create rte_hash=0A= > structure.=0A= > As part of this, this api initalized the rte_hash structure and set the= =0A= > srcHash->rte_hash_cmp_eq to the address of memcmp() from proc1 address=0A= > space.=0A= >=0A= > proc2:=0A= > calls srcHash =3D rte_hash_find_existing("src_hash_name"). This returns = the=0A= > rte_hash created by proc1.=0A= > This srcHash->rte_hash_cmp_eq still points to the address of memcmp() fro= m=0A= > proc1 address space.=0A= > Later proc2 calls rte_hash_lookup_with_hash(srcHash, (const void*) &key,= =0A= > key.sig);=0A= > Under the hood, rte_hash_lookup_with_hash() invokes=0A= > __rte_hash_lookup_with_hash(), which in turn calls h->rte_hash_cmp_eq(key= ,=0A= > k->key, h->key_len).=0A= > This leads to a crash as h->rte_hash_cmp_eq is an address from proc1=0A= > address space and is invalid address in proc2 address space.=0A= >=0A= > We found, from dpdk documentation, that=0A= > "=0A= > The use of function pointers between multiple processes running based of= =0A= > different compiled=0A= > binaries is not supported, since the location of a given function in one= =0A= > process may be different to=0A= > its location in a second. This prevents the librte_hash library from=0A= > behaving properly as in a multi-=0A= > threaded instance, since it uses a pointer to the hash function internal= ly.=0A= >=0A= >=0A= > To work around this issue, it is recommended that multi-process=0A= > applications perform the hash=0A= > calculations by directly calling the hashing function from the code and= =0A= > then using the=0A= > rte_hash_add_with_hash()/rte_hash_lookup_with_hash() functions instead o= f=0A= > the functions which do=0A= > the hashing internally, such as rte_hash_add()/rte_hash_lookup().=0A= > "=0A= >=0A= > We did follow the recommended steps by invoking rte_hash_lookup_with_hash= ().=0A= > It was no issue up to and including dpdk-2.0. In later releases started= =0A= > crashing because rte_hash_cmp_eq is introduced in dpdk-2.1=0A= >=0A= > We fixed it with the following patch and would like to submit the patch t= o=0A= > dpdk.org.=0A= =0A= Could you send the patch in the mail?=0A= =0A= Learn how to send a patch:=0A= =0A= http://www.dpdk.org/dev=0A= =0A= Thanks,=0A= Michael=0A= > Patch is created such that, if anyone wanted to use dpdk in multi-process= =0A= > environment with function pointers not shared, they need to=0A= > define RTE_LIB_MP_NO_FUNC_PTR in their Makefile. Without defining this fl= ag=0A= > in Makefile, it works as it is now.=0A= >=0A= >=0A= > Please find here attached is the patch file.=0A= >=0A= > Thanks=0A= > Dhana=0A= >=0A= =0A=