From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"Vangati, Narender" <narender.vangati@intel.com>,
"Eads, Gage" <gage.eads@intel.com>
Subject: Re: [dpdk-dev] [RFC] service core concept header implementation
Date: Sat, 6 May 2017 19:56:15 +0530 [thread overview]
Message-ID: <20170506142613.GA15598@jerin> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA612A3586E@IRSMSX102.ger.corp.intel.com>
-----Original Message-----
> Date: Fri, 5 May 2017 15:48:02 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, "Richardson, Bruce"
> <bruce.richardson@intel.com>, "hemant.agrawal@nxp.com"
> <hemant.agrawal@nxp.com>, "nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
> "Vangati, Narender" <narender.vangati@intel.com>, "Eads, Gage"
> <gage.eads@intel.com>
> Subject: RE: [RFC] service core concept header implementation
>
>
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> <snip email headers>
> > > Hi Harry,
> > >
> > > Overall it looks good. Some initial comments
>
> Off to a good start! Replies inline, in general I think we're on the same page. This RFC was pretty "fresh", mostly to check if the community agrees with the general concept of service-cores. The implementation details (although going well) will have some churn I expect :)
>
> I'd like opinions from others in the community - I'll leave this thread "open" for a while to get more feedback, and rework a v2 RFC then.
>
> Thanks for your review - Harry
>
>
> > >
> > > Regarding step 4 and 5, It looks like,
> > > a) The lcore_id information is duplicate in step 4 and 5.
>
>
> Not really duplicated - keep in mind we do not want to have a 1:1 mapping, the goal of this is to allow e.g. 3 cores -> 5 services type mappings, where the work is shared between the cores. Hence, setting coremasks and setting lcores to use are very related, but not quite the same.
>
>
> > > b) On rte_eal_service_set_coremask() failure, you may the need
> > > inverse of rte_eal_service_use_lcore()(setting back to worker/normal
> > > lcore)
>
> We can pass the "type" of lcore as an argument to a function:
>
> #define RTE_EAL_SERVICE_TYPE_APPLICATION 0
> #define RTE_EAL_SERVICE_TYPE_SERVICE 1
>
> rte_eal_service_set_lcore_type(uint32_t type);
>
> Allows adding more core types (if anybody can think of any) and avoids function-count bloat :)
>
>
> > > But I understand the need for step 5.
> > >
> > > How about changing the (4) and (5) as
> > >
> > > step 4) rte_eal_service_set_coremask
> > > step 5) rte_eal_service_apply(void)(or similar name) for error check and
> > > ensure at least on core is going to be running the service.
>
> So the sequence would be:
>
> for( i < app_n_service_cores )
> rte_eal_service_set_lcore_type( SERVICE );
>
> for( i < services_count )
> rte_eal_serivce_set_coremask( app_decided_coremask_here );
I thought, The application may not need to set the explicit
rte_eal_service_set_lcore_type, it can be internally set by
rte_eal_service_set_coremask
i.e
for( i < services_count )
rte_eal_service_set_coremask( app_decided_coremask_here );
int ret = rte_eal_service_apply();
rte_eal_service_set_coremask(app_decided_coremask_here)
{
proposed_implementation;
for_each_bit_set(app_decided_coremask_here)
rte_eal_service_set_lcore_type(SERVICE);
}
>
> int ret = rte_eal_service_apply();
>
> if(ret) {
> /* application can rte_panic(), or reset CPU cores to default APP state and continue */
> }
>
> /* application profits from service-cores feature in EAL */
>
> > 2) What would be the tear down sequence of the service core especially when
> > device stop or close happens?
>
> Good question. Being able to "turn off" a single service while keeping other services running would be useful I think. That might require some extra tracking at the implementation layer, but perhaps something that's worth doing. Opinions and use-cases welcome here!
I think it makes sense to add "turn off" support for each service
functions as we are multiplexing the service core.
>
>
>
next prev parent reply other threads:[~2017-05-06 14:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 11:29 [dpdk-dev] [RFC] Service Cores concept Harry van Haaren
2017-05-03 11:29 ` [dpdk-dev] [RFC] service core concept header implementation Harry van Haaren
2017-05-04 6:35 ` Jerin Jacob
2017-05-04 12:01 ` Jerin Jacob
2017-05-05 15:48 ` Van Haaren, Harry
2017-05-06 14:26 ` Jerin Jacob [this message]
2017-05-17 12:47 ` Ananyev, Konstantin
2017-05-17 12:58 ` Bruce Richardson
2017-05-17 13:47 ` Ananyev, Konstantin
2017-05-25 13:27 ` Van Haaren, Harry
2017-05-16 22:11 ` [dpdk-dev] [RFC] Service Cores concept Thomas Monjalon
2017-05-16 22:48 ` Wiles, Keith
2017-05-17 10:32 ` Bruce Richardson
2017-05-17 11:28 ` Thomas Monjalon
2017-05-17 12:36 ` Bruce Richardson
2017-05-17 14:51 ` [dpdk-dev] Discuss plugin threading model for DPDK Wiles, Keith
2017-05-17 15:46 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170506142613.GA15598@jerin \
--to=jerin.jacob@caviumnetworks.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=narender.vangati@intel.com \
--cc=nipun.gupta@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).