From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 390B211D4 for ; Tue, 22 Mar 2016 20:53:51 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 22 Mar 2016 12:53:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,378,1455004800"; d="scan'208";a="916673223" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga001.jf.intel.com with ESMTP; 22 Mar 2016 12:53:47 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.13]) by IRSMSX106.ger.corp.intel.com ([169.254.8.172]) with mapi id 14.03.0248.002; Tue, 22 Mar 2016 19:53:44 +0000 From: "De Lara Guarch, Pablo" To: Thomas Monjalon , "Gonzalez Monroy, Sergio" CC: "dev@dpdk.org" , Dhana Eadala , "Richardson, Bruce" , "Qiu, Michael" Thread-Topic: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment Thread-Index: AQHRfZeeszvoymnzZEiI/Y2CPwSy059lZI6AgACI7DA= Date: Tue, 22 Mar 2016 19:53:43 +0000 Message-ID: References: <1457921808-14261-1-git-send-email-edreddy@gmail.com> <76801321.W6WWktetkp@xps13> In-Reply-To: <76801321.W6WWktetkp@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWVjYmJjODUtYTU1Mi00ODg1LWI1NWItYjMyNjNjYzE2NTc1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik9vZlwvWFpZaGtNa3o4VDkrblJ3SXNPVjNHS1dHc21jRExrNFN0cUQ2YkxzPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 19:53:51 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, March 22, 2016 11:42 AM > To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio > Cc: dev@dpdk.org; Dhana Eadala; Richardson, Bruce; Qiu, Michael > Subject: Re: [dpdk-dev] [PATCH] hash: fix memcmp function pointer in mult= i- > process environment >=20 > Hi, >=20 > Pablo, Sergio, please could you help with this issue? I agree this is not the best way to fix this. I will try to have a fix with= out having to use ifdefs. Thanks, Pablo >=20 > 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 =3D 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 =3D 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 intern= ally. > > > > 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. >=20 > Introducing #ifdef RTE_LIB_MP_NO_FUNC_PTR is not recommended.