-----Original Message----- > Date: Thu, 29 Jun 2017 16:57:08 +0100 > From: Bruce Richardson <bruce.richard...@intel.com> > To: "Van Haaren, Harry" <harry.van.haa...@intel.com> > CC: "dev@dpdk.org" <dev@dpdk.org>, 'Jerin Jacob' > <jerin.ja...@caviumnetworks.com>, "tho...@monjalon.net" > <tho...@monjalon.net>, "Wiles, Keith" <keith.wi...@intel.com> > Subject: Re: Service lcores and Application lcores > User-Agent: Mutt/1.8.1 (2017-04-11) > > On Thu, Jun 29, 2017 at 03:36:04PM +0100, Van Haaren, Harry wrote: > > Hi All, > > > > > > The recently posted service cores patchset[1], introduces service lcores to > > run services for DPDK applications. Services are just an ordinary function > > for eg: eventdev scheduling, NIC RX, statistics and monitoring, etc. A > > service is just a callback function, which a core invokes. An atomic > > ensures that services that are > > non-multi-thread-safe are never concurrently invoked. > > > > The topic of discussion in this thread is how we can ensure that > > application lcores do not interfere with service cores. I have a solution > > described below, opinions welcome. > > > > > > Regards, -Harry > > > > > > PS: This discussion extends that in the ML thread here[2], participants of > > that thread added to CC. > > > > [1] Service Cores v2 patchset > > http://dpdk.org/dev/patchwork/bundle/hvanhaar/service_cores_v2/ > > [2] http://dpdk.org/ml/archives/dev/2017-June/069290.html > > > > > > ________________________ > > > > > > > > A proposal for Eventdev, to ensure Service lcores and Application lcores > > play nice; > > > > 1) Application lcores must not directly call rte_eventdev_schedule() > > 2A) Service cores are the proper method to run services > > 2B) If an application insists on running a service "manually" on an app > > lcore, we provide a function for that: > > rte_service_run_from_app_lcore(struct service *srv); > > > > The above function would allow a pesky app to run services on its own > > (non-service core) lcores, but > > does so through the service-core framework, allowing the service-library > > atomic to keep access serialized as required for non-multi-thread-safe > > services. > > > > The above solution maintains the option of running the eventdev PMD as now > > (single-core dedicated to a single service), while providing correct > > serialization by using the rte_service_run_from_app_lcore() function. Given > > the atomic is only used when required (multiple cores mapped to the > > service) there should be no performance delta. > > > > Given that the application should not invoke rte_eventdev_schedule(), we > > could even consider removing it from the Eventdev API. A PMD that requires > > cycles registers a service, and an application can use a service core or > > the run_from_app_lcore() function if it wishes to invoke that service on an > > application owned lcore. > > > > > > Opinions? > > I would be in favour of this proposal, except for the proposed name for > the new function. It would be useful for an app to be able to "adopt" a > service into it's main loop if so desired. If we do this, I think I'd
+1 Agree with Harry and Bruce here. I think, The adapter function should take "struct service *" and return lcore_function_t so that it can run using exiting rte_eal_remote_launch() > also support the removal of a dedicated schedule call from the eventdev > API, or alternatively, if it is needed by other PMDs, leave it as a > no-op in the sw PMD in favour of the service-cores managed function. I would be in favor of removing eventdev schedule and RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability so that it is completely transparent to application whether scheduler runs on HW or SW or "combination of both" > > /Bruce
