From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id ED43610A3 for ; Thu, 17 Jan 2019 14:41:44 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2019 05:41:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,489,1539673200"; d="scan'208";a="119254715" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga003.jf.intel.com with ESMTP; 17 Jan 2019 05:41:43 -0800 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 05:41:43 -0800 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.99]) by fmsmsx118.amr.corp.intel.com ([169.254.1.120]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 05:41:43 -0800 From: "Pathak, Pravin" To: "Van Haaren, Harry" , "users@dpdk.org" Thread-Topic: Service cores and multi-process Thread-Index: AdSuEKfKIno6t6uXTtO2OWWL9vGL2AAPPaaAAAaKKNAAACHN4AAAfNqg Date: Thu, 17 Jan 2019 13:41:43 +0000 Message-ID: <168A68C163D584429EF02A476D5274424DEA936C@FMSMSX108.amr.corp.intel.com> References: <168A68C163D584429EF02A476D5274424DEA9097@FMSMSX108.amr.corp.intel.com> <168A68C163D584429EF02A476D5274424DEA932B@FMSMSX108.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmM1ZDA2OWQtMjhhNy00MjQ4LTk4NjgtMjhiMTcxNWM4ZGZlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSnJaQW9WVzFuOG5lK2NxMDhpeXk2REJaNFwveEgxaVZsNDU3XC8xNWJZSUpcL24rRGZWZlhZZDBsd2syVzhlN0haWiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-users] Service cores and multi-process X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 13:41:45 -0000 Thanks a lot Harry. It is clear to me now. Pravin -----Original Message----- From: Van Haaren, Harry=20 Sent: Thursday, January 17, 2019 8:34 AM To: Pathak, Pravin ; users@dpdk.org Subject: RE: Service cores and multi-process > -----Original Message----- > From: Pathak, Pravin > Sent: Thursday, January 17, 2019 1:26 PM > To: Van Haaren, Harry ; users@dpdk.org > Subject: RE: Service cores and multi-process >=20 > Hi Harry - Hey, [Side-note] Please reply inline on mailing-lists, it makes it easier to fol= low the conversation than "top posting". > Thanks. Extending the same question further, if two processes=20 > (within same DPDK instance) need same service, then should they both=20 > specify same service core mask? This depends on what you want to achieve. If both processes need their own = instance of the service, have each process individually register the servic= e, and both processes (primary & secondary) will require a service core to = run them. The alternative is to use the DPDK hugepage shared memory to run a service = in one process (so only that process requires the service-core), and allow = both processes to enqueue/dequeue to that core. For simplicity, I would recommend keeping services "process local" where po= ssible. > I assumed primary process will start the service on service cores and=20 > secondary process (using same service core mask) will use the service. No, this is not the case. Keep in mind that a "service" is just really just a function pointer and vo= id* userdata. A "service core" is just a thread that calls the function pointer with its = void* arg. Because it's a function-pointer, it is inherently tied to a specific proces= s, sharing function-pointers across process boundaries is not possible (esp= ecially with ASLR enabled). > Thanks > Pravin >=20 >=20 > -----Original Message----- > From: Van Haaren, Harry > Sent: Thursday, January 17, 2019 5:17 AM > To: Pathak, Pravin ; users@dpdk.org > Subject: RE: Service cores and multi-process >=20 > Hi Pravin, >=20 > > -----Original Message----- > > From: users [mailto:users-bounces@dpdk.org] On Behalf Of Pathak,=20 > > Pravin > > Sent: Thursday, January 17, 2019 3:02 AM > > To: users@dpdk.org > > Subject: [dpdk-users] Service cores and multi-process > > > > Hi All - > > > > In case of DPDK multi-process mode, do we need to give same service=20 > > core masks for all process invocation? >=20 > No it is not required to give the exact same service-core mask. > This is the same for "normal" DPDK lcores - they can be different in=20 > the secondary than they are in the primary. >=20 >=20 > > Regards > > Pravin >=20 > Regards, -Harry