From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 723725699 for ; Thu, 29 Jun 2017 13:15:34 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 04:15:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,280,1496127600"; d="scan'208";a="120725134" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga006.fm.intel.com with ESMTP; 29 Jun 2017 04:15:32 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.211]) by irsmsx110.ger.corp.intel.com ([169.254.15.126]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 12:15:31 +0100 From: "Van Haaren, Harry" To: 'Jerin Jacob' CC: "dev@dpdk.org" , "thomas@monjalon.net" , "Wiles, Keith" , "Richardson, Bruce" Thread-Topic: [PATCH 6/6] service cores: enable event/sw with service Thread-Index: AQHS7AAJAOlj37O0V0S2zhX0ft6ptqI3HJSAgAGhZKA= Date: Thu, 29 Jun 2017 11:15:31 +0000 Message-ID: References: <1498208779-166205-1-git-send-email-harry.van.haaren@intel.com> <1498208779-166205-6-git-send-email-harry.van.haaren@intel.com> <20170626134654.GA14871@jerin> In-Reply-To: <20170626134654.GA14871@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzhlOGU5MDQtZGViYi00NWIwLTg1MDgtMjJhOWUyMTlkZDBmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNi41LjkuMyIsIlRydXN0ZWRMYWJlbEhhc2giOiJRK2NYQmhmazJ5NjM5NHZlbVwvSnZsSG5GWDRNMFwvM0N1eEsyaHFBWGZpdEk9In0= x-ctpclassification: CTP_PUBLIC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action 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 6/6] service cores: enable event/sw with service X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 11:15:35 -0000 > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Monday, June 26, 2017 2:47 PM > To: Van Haaren, Harry > Cc: dev@dpdk.org; thomas@monjalon.net; Wiles, Keith ; Richardson, > Bruce > Subject: Re: [PATCH 6/6] service cores: enable event/sw with service >=20 > -----Original Message----- > > Date: Fri, 23 Jun 2017 10:06:19 +0100 > > From: Harry van Haaren > > +#include > > +#include >=20 > If rte_service_private.h needs the rte_cycles.h then I think it can be > included in rte_service_private.h. Actually it was stale, a leftover from during development - removed. > > + /* register service with EAL */ > > + struct rte_service_spec service; > > + memset(&service, 0, sizeof(struct rte_service_spec)); > > + snprintf(service.name, sizeof(service.name), "%s_service", name); >=20 > Should we add socket_id as well in the service name? The user can name the PMD instance with socket ID if they so wish. The name= of the PMD instance must already be unique - so we won't gain anything by = adding socket ID there either... I'm not seeing value? The socket ID is available to the application by reading struct service_s= pec. > > + service.socket_id =3D socket_id; > > + service.callback =3D sw_sched_service_func; > > + service.callback_userdata =3D (void *)dev; > > + > > + int32_t ret =3D rte_service_register(&service); > > + printf("serivce register =3D %d, cb ud %p\n", ret, dev); >=20 > sw_pmd_log? Removed - little value in seeing pointer values bar during development :) > > + > > return 0; >=20 > Should we also check rte_service_is_running() in sw pmd start function > to verify application did everything to setup the service function on > service lcore? or means for feedback? Yes good idea - rte_service_is_running will return true if the service call= back will be called by at least one service lcore - exactly what we need to= check. This check is implemented in v2, on the way soon. As noted in the first ema= il, I'll kick off a mail about discussing how to best use service-cores, an= d how to enable applications benefit most from service cores (including not= using them if they don't want to :)