[RFC] replace master/slave with primary/secondary
Checks
Commit Message
I have a full patch that replaces the master/slave lcore
naming (widely used in DPDK) with a better primary/secondary naming.
For now this is just a trial balloon to see what the impact would
look like. The change mostly automated so likely that things
are broken.
It is hard to break a change like this down, and still
keep git bisection clean.
It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
items so that user code can still be built but they will be motivated
to change.
Here is a sample of what it would look like:
Comments
On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> I have a full patch that replaces the master/slave lcore
> naming (widely used in DPDK) with a better primary/secondary naming.
>
> For now this is just a trial balloon to see what the impact would
> look like. The change mostly automated so likely that things
> are broken.
>
> It is hard to break a change like this down, and still
> keep git bisection clean.
>
> It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
> items so that user code can still be built but they will be motivated
> to change.
>
> Here is a sample of what it would look like:
>
I think PRIMARY is a poor choice to describe the control thread. PRIMARY
is often used to designate the active element currently doing the work.
SECONDARY threads are also active threads doing equal dataplane work.
Another issue I see with primary / secondary is the ambiguity with
multi-process in DPDK. Doc readers could get confused about where a
primary / secondary thread is executed.
I think we could use instead DPDK-specific terminology. The lcore
organization is a little specific, with an lcore that does most init work
and spawns the others, but then runs the application like all others.
I'd propose instead leader lcore - there is this idea that the leader
is still a member of the team and will participate in the work.
Leader / worker?
>
> On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> > I have a full patch that replaces the master/slave lcore
> > naming (widely used in DPDK) with a better primary/secondary naming.
> >
> > For now this is just a trial balloon to see what the impact would
> > look like. The change mostly automated so likely that things
> > are broken.
> >
> > It is hard to break a change like this down, and still
> > keep git bisection clean.
> >
> > It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
> > items so that user code can still be built but they will be motivated
> > to change.
> >
> > Here is a sample of what it would look like:
> >
>
> I think PRIMARY is a poor choice to describe the control thread. PRIMARY
> is often used to designate the active element currently doing the work.
> SECONDARY threads are also active threads doing equal dataplane work.
>
> Another issue I see with primary / secondary is the ambiguity with
> multi-process in DPDK. Doc readers could get confused about where a
> primary / secondary thread is executed.
>
> I think we could use instead DPDK-specific terminology. The lcore
> organization is a little specific, with an lcore that does most init work
> and spawns the others, but then runs the application like all others.
>
> I'd propose instead leader lcore - there is this idea that the leader
> is still a member of the team and will participate in the work.
>
> Leader / worker?
>
I personally doubt such changes are needed at all.
Code churn will be massive for both DPDK itself and related user projects.
With no real gain in return, from my perspective.
Konstantin
On Fri, Jun 05, 2020 at 12:43:00PM +0200, Gaëtan Rivet wrote:
> On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> > I have a full patch that replaces the master/slave lcore
> > naming (widely used in DPDK) with a better primary/secondary naming.
> >
> > For now this is just a trial balloon to see what the impact would
> > look like. The change mostly automated so likely that things
> > are broken.
> >
> > It is hard to break a change like this down, and still
> > keep git bisection clean.
> >
> > It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
> > items so that user code can still be built but they will be motivated
> > to change.
> >
> > Here is a sample of what it would look like:
> >
>
> I think PRIMARY is a poor choice to describe the control thread. PRIMARY
> is often used to designate the active element currently doing the work.
> SECONDARY threads are also active threads doing equal dataplane work.
>
> Another issue I see with primary / secondary is the ambiguity with
> multi-process in DPDK. Doc readers could get confused about where a
> primary / secondary thread is executed.
>
> I think we could use instead DPDK-specific terminology. The lcore
> organization is a little specific, with an lcore that does most init work
> and spawns the others, but then runs the application like all others.
>
> I'd propose instead leader lcore - there is this idea that the leader
> is still a member of the team and will participate in the work.
>
> Leader / worker?
>
No sure I like the term "Leader" for a thread, but "worker" is an ok name.
How about "init thread" and "worker threads"?
/Bruce
On 05/06/20 12:28 +0100, Bruce Richardson wrote:
> On Fri, Jun 05, 2020 at 12:43:00PM +0200, Gaëtan Rivet wrote:
> > On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> > > I have a full patch that replaces the master/slave lcore
> > > naming (widely used in DPDK) with a better primary/secondary naming.
> > >
> > > For now this is just a trial balloon to see what the impact would
> > > look like. The change mostly automated so likely that things
> > > are broken.
> > >
> > > It is hard to break a change like this down, and still
> > > keep git bisection clean.
> > >
> > > It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
> > > items so that user code can still be built but they will be motivated
> > > to change.
> > >
> > > Here is a sample of what it would look like:
> > >
> >
> > I think PRIMARY is a poor choice to describe the control thread. PRIMARY
> > is often used to designate the active element currently doing the work.
> > SECONDARY threads are also active threads doing equal dataplane work.
> >
> > Another issue I see with primary / secondary is the ambiguity with
> > multi-process in DPDK. Doc readers could get confused about where a
> > primary / secondary thread is executed.
> >
> > I think we could use instead DPDK-specific terminology. The lcore
> > organization is a little specific, with an lcore that does most init work
> > and spawns the others, but then runs the application like all others.
> >
> > I'd propose instead leader lcore - there is this idea that the leader
> > is still a member of the team and will participate in the work.
> >
> > Leader / worker?
> >
> No sure I like the term "Leader" for a thread, but "worker" is an ok name.
> How about "init thread" and "worker threads"?
>
> /Bruce
Init was actually my first idea :) . I thought leader could be more
palatable in some documentation, but after some tests I think init
thread could work better after all.
I was thinking init / spawned threads first, but worker is ok.
On Fri, 5 Jun 2020 12:43:00 +0200
Gaëtan Rivet <grive@u256.net> wrote:
> On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> > I have a full patch that replaces the master/slave lcore
> > naming (widely used in DPDK) with a better primary/secondary naming.
> >
> > For now this is just a trial balloon to see what the impact would
> > look like. The change mostly automated so likely that things
> > are broken.
> >
> > It is hard to break a change like this down, and still
> > keep git bisection clean.
> >
> > It keeps rte_master_lcore_id and RTE_FOREACH_SLAVE as deprecated
> > items so that user code can still be built but they will be motivated
> > to change.
> >
> > Here is a sample of what it would look like:
> >
>
> I think PRIMARY is a poor choice to describe the control thread. PRIMARY
> is often used to designate the active element currently doing the work.
> SECONDARY threads are also active threads doing equal dataplane work.
>
> Another issue I see with primary / secondary is the ambiguity with
> multi-process in DPDK. Doc readers could get confused about where a
> primary / secondary thread is executed.
>
> I think we could use instead DPDK-specific terminology. The lcore
> organization is a little specific, with an lcore that does most init work
> and spawns the others, but then runs the application like all others.
>
> I'd propose instead leader lcore - there is this idea that the leader
> is still a member of the team and will participate in the work.
>
> Leader / worker?
>
Looking at Django the chose leader/follower.
Other alternatives are:
agency/operative
hive/drone
primary/handler
conductor/doer
captain/conscript
schemer/patsies
primary/replica
On Fri, 5 Jun 2020 11:14:50 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > organization is a little specific, with an lcore that does most init work
> > and spawns the others, but then runs the application like all others.
> >
> > I'd propose instead leader lcore - there is this idea that the leader
> > is still a member of the team and will participate in the work.
> >
> > Leader / worker?
> >
>
> I personally doubt such changes are needed at all.
> Code churn will be massive for both DPDK itself and related user projects.
> With no real gain in return, from my perspective.
> Konstantin
>
Your concern is valid but the issue does need to be addressed.
If now when? This is as a good a time as any to do it.
Increasing diversity and inclusion is an overarching goal of many organizations
include my employer(Microsoft), the parent organization of DPDK(LF)
and my values.
Following values is more important than minor replacement of text in API.
> On Jun 5, 2020, at 11:33 AM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Fri, 5 Jun 2020 11:14:50 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
>>> organization is a little specific, with an lcore that does most init work
>>> and spawns the others, but then runs the application like all others.
>>>
>>> I'd propose instead leader lcore - there is this idea that the leader
>>> is still a member of the team and will participate in the work.
>>>
>>> Leader / worker?
>>>
>>
>> I personally doubt such changes are needed at all.
>> Code churn will be massive for both DPDK itself and related user projects.
>> With no real gain in return, from my perspective.
>> Konstantin
>>
>
> Your concern is valid but the issue does need to be addressed.
> If now when? This is as a good a time as any to do it.
>
> Increasing diversity and inclusion is an overarching goal of many organizations
> include my employer(Microsoft), the parent organization of DPDK(LF)
> and my values.
>
> Following values is more important than minor replacement of text in API.
I feel like Konstantin is correct here.
If we were using these terms for humans or groups of humans, then I would agree they should be changed. We need to take into account the context of the reference to these words. I agree some words should never be used in any context, but these terms are very reasonable in the context of DPDK and networking.
If everyone wants to accept the code churn (and it will effect a large number of applications, plus back porting will be more difficult IMO), then we can do it.
On Fri, 5 Jun 2020 17:10:05 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:
> >>>
> >>> I'd propose instead leader lcore - there is this idea that the leader
> >>> is still a member of the team and will participate in the work.
> >>>
> >>> Leader / worker?
> >>>
> >>
> >> I personally doubt such changes are needed at all.
> >> Code churn will be massive for both DPDK itself and related user projects.
> >> With no real gain in return, from my perspective.
> >> Konstantin
> >>
> >
> > Your concern is valid but the issue does need to be addressed.
> > If now when? This is as a good a time as any to do it.
> >
> > Increasing diversity and inclusion is an overarching goal of many organizations
> > include my employer(Microsoft), the parent organization of DPDK(LF)
> > and my values.
> >
> > Following values is more important than minor replacement of text in API.
>
> I feel like Konstantin is correct here.
>
> If we were using these terms for humans or groups of humans, then I would agree they should be changed. We need to take into account the context of the reference to these words. I agree some words should never be used in any context, but these terms are very reasonable in the context of DPDK and networking.
Have to disagree, the words matter. This has been discussed many times.
Please look at the footnotes from the Gnome post
[0] - <https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>, <https://twitter.com/justkelly_ok/status/933011085594066944>
[1] - <https://github.com/django/django/pull/2692>
[2] - <https://bugs.python.org/issue34605>
[3] - <https://github.com/rust-lang-deprecated/rust-buildbot/issues/2>, <https://github.com/rust-community/foss-events-planner/issues/58>
[4] - <https://twitter.com/ISCdotORG/status/942815837299253248>
[5] - <https://gitlab.gnome.org/GNOME/geary/issues/324>
> On Jun 5, 2020, at 12:45 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Fri, 5 Jun 2020 17:10:05 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>>>>>
>>>>> I'd propose instead leader lcore - there is this idea that the leader
>>>>> is still a member of the team and will participate in the work.
>>>>>
>>>>> Leader / worker?
>>>>>
>>>>
>>>> I personally doubt such changes are needed at all.
>>>> Code churn will be massive for both DPDK itself and related user projects.
>>>> With no real gain in return, from my perspective.
>>>> Konstantin
>>>>
>>>
>>> Your concern is valid but the issue does need to be addressed.
>>> If now when? This is as a good a time as any to do it.
>>>
>>> Increasing diversity and inclusion is an overarching goal of many organizations
>>> include my employer(Microsoft), the parent organization of DPDK(LF)
>>> and my values.
>>>
>>> Following values is more important than minor replacement of text in API.
>>
>> I feel like Konstantin is correct here.
>>
>> If we were using these terms for humans or groups of humans, then I would agree they should be changed. We need to take into account the context of the reference to these words. I agree some words should never be used in any context, but these terms are very reasonable in the context of DPDK and networking.
>
> Have to disagree, the words matter. This has been discussed many times.
> Please look at the footnotes from the Gnome post
>
>
> [0] - <https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>, <https://twitter.com/justkelly_ok/status/933011085594066944>
>
> [1] - <https://github.com/django/django/pull/2692>
> [2] - <https://bugs.python.org/issue34605>
>
> [3] - <https://github.com/rust-lang-deprecated/rust-buildbot/issues/2>, <https://github.com/rust-community/foss-events-planner/issues/58>
>
> [4] - <https://twitter.com/ISCdotORG/status/942815837299253248>
> [5] - <https://gitlab.gnome.org/GNOME/geary/issues/324>
You chopped off my last sentence in your reply.
"If everyone wants to accept the code churn (and it will effect a large number of applications, plus back porting will be more difficult IMO), then we can do it."
So to be clear, I am not opposed to making this change, but wanted to point out the technical impacts of this change to DPDK as a whole.
On Fri, 5 Jun 2020 19:23:52 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:
> > On Jun 5, 2020, at 12:45 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >
> > On Fri, 5 Jun 2020 17:10:05 +0000
> > "Wiles, Keith" <keith.wiles@intel.com> wrote:
> >
> >>>>>
> >>>>> I'd propose instead leader lcore - there is this idea that the leader
> >>>>> is still a member of the team and will participate in the work.
> >>>>>
> >>>>> Leader / worker?
> >>>>>
> >>>>
> >>>> I personally doubt such changes are needed at all.
> >>>> Code churn will be massive for both DPDK itself and related user projects.
> >>>> With no real gain in return, from my perspective.
> >>>> Konstantin
> >>>>
> >>>
> >>> Your concern is valid but the issue does need to be addressed.
> >>> If now when? This is as a good a time as any to do it.
> >>>
> >>> Increasing diversity and inclusion is an overarching goal of many organizations
> >>> include my employer(Microsoft), the parent organization of DPDK(LF)
> >>> and my values.
> >>>
> >>> Following values is more important than minor replacement of text in API.
> >>
> >> I feel like Konstantin is correct here.
> >>
> >> If we were using these terms for humans or groups of humans, then I would agree they should be changed. We need to take into account the context of the reference to these words. I agree some words should never be used in any context, but these terms are very reasonable in the context of DPDK and networking.
> >
> > Have to disagree, the words matter. This has been discussed many times.
> > Please look at the footnotes from the Gnome post
> >
> >
> > [0] - <https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>, <https://twitter.com/justkelly_ok/status/933011085594066944>
> >
> > [1] - <https://github.com/django/django/pull/2692>
> > [2] - <https://bugs.python.org/issue34605>
> >
> > [3] - <https://github.com/rust-lang-deprecated/rust-buildbot/issues/2>, <https://github.com/rust-community/foss-events-planner/issues/58>
> >
> > [4] - <https://twitter.com/ISCdotORG/status/942815837299253248>
> > [5] - <https://gitlab.gnome.org/GNOME/geary/issues/324>
>
> You chopped off my last sentence in your reply.
>
> "If everyone wants to accept the code churn (and it will effect a large number of applications, plus back porting will be more difficult IMO), then we can do it."
>
> So to be clear, I am not opposed to making this change, but wanted to point out the technical impacts of this change to DPDK as a whole.
Thanks, my editing was not intended to be a way to stifling your response.
How many applications try to support multiple DPDK major versions at once?
> On Jun 5, 2020, at 2:53 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Fri, 5 Jun 2020 19:23:52 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>
>>> On Jun 5, 2020, at 12:45 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>>
>>> On Fri, 5 Jun 2020 17:10:05 +0000
>>> "Wiles, Keith" <keith.wiles@intel.com> wrote:
>>>
>>>>>>>
>>>>>>> I'd propose instead leader lcore - there is this idea that the leader
>>>>>>> is still a member of the team and will participate in the work.
>>>>>>>
>>>>>>> Leader / worker?
>>>>>>>
>>>>>>
>>>>>> I personally doubt such changes are needed at all.
>>>>>> Code churn will be massive for both DPDK itself and related user projects.
>>>>>> With no real gain in return, from my perspective.
>>>>>> Konstantin
>>>>>>
>>>>>
>>>>> Your concern is valid but the issue does need to be addressed.
>>>>> If now when? This is as a good a time as any to do it.
>>>>>
>>>>> Increasing diversity and inclusion is an overarching goal of many organizations
>>>>> include my employer(Microsoft), the parent organization of DPDK(LF)
>>>>> and my values.
>>>>>
>>>>> Following values is more important than minor replacement of text in API.
>>>>
>>>> I feel like Konstantin is correct here.
>>>>
>>>> If we were using these terms for humans or groups of humans, then I would agree they should be changed. We need to take into account the context of the reference to these words. I agree some words should never be used in any context, but these terms are very reasonable in the context of DPDK and networking.
>>>
>>> Have to disagree, the words matter. This has been discussed many times.
>>> Please look at the footnotes from the Gnome post
>>>
>>>
>>> [0] - <https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt>, <https://twitter.com/justkelly_ok/status/933011085594066944>
>>>
>>> [1] - <https://github.com/django/django/pull/2692>
>>> [2] - <https://bugs.python.org/issue34605>
>>>
>>> [3] - <https://github.com/rust-lang-deprecated/rust-buildbot/issues/2>, <https://github.com/rust-community/foss-events-planner/issues/58>
>>>
>>> [4] - <https://twitter.com/ISCdotORG/status/942815837299253248>
>>> [5] - <https://gitlab.gnome.org/GNOME/geary/issues/324>
>>
>> You chopped off my last sentence in your reply.
>>
>> "If everyone wants to accept the code churn (and it will effect a large number of applications, plus back porting will be more difficult IMO), then we can do it."
>>
>> So to be clear, I am not opposed to making this change, but wanted to point out the technical impacts of this change to DPDK as a whole.
>
>
> Thanks, my editing was not intended to be a way to stifling your response.
> How many applications try to support multiple DPDK major versions at once?
>
NP, I understand it was not intended, but wanted to make sure it was not lost.
In Pktgen I try to support back to 18.11 release and some have asked for 18.04, one asked for 16.04 :-) I most likely do not do it very well, but I try given the limited time I have.
The big churn happened in 19.05 I think when all of the APIs and defines changed. It took me a few days to create a compat file to support backward compatibility .
I try to tell everyone I only support the latest release of DPDK and latest release of Pktgen, but that does not fly very well for some customers.
I would hope we can make this change and create methods to allow for supporting backward compatibility without every application having to create the compatibility support themselves.
Let me know how I can help,
Thanks
@@ -32,12 +32,12 @@ typedef int (lcore_function_t)(void *);
/**
* Launch a function on another lcore.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the PRIMARY lcore only.
*
- * Sends a message to a slave lcore (identified by the slave_id) that
+ * Sends a message to a secondary lcore (identified by the id) that
* is in the WAIT state (this is true after the first call to
* rte_eal_init()). This can be checked by first calling
- * rte_eal_wait_lcore(slave_id).
+ * rte_eal_wait_lcore(id).
*
* When the remote lcore receives the message, it switches to
* the RUNNING state, then calls the function f with argument arg. Once the
@@ -45,7 +45,7 @@ typedef int (lcore_function_t)(void *);
* the return value of f is stored in a local variable to be read using
* rte_eal_wait_lcore().
*
- * The MASTER lcore returns as soon as the message is sent and knows
+ * The PRIMARY lcore returns as soon as the message is sent and knows
* nothing about the completion of f.
*
* Note: This function is not designed to offer optimum
@@ -56,37 +56,37 @@ typedef int (lcore_function_t)(void *);
* The function to be called.
* @param arg
* The argument for the function.
- * @param slave_id
+ * @param id
* The identifier of the lcore on which the function should be executed.
* @return
* - 0: Success. Execution of function f started on the remote lcore.
* - (-EBUSY): The remote lcore is not in a WAIT state.
*/
-int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned slave_id);
+int rte_eal_remote_launch(lcore_function_t *f, void *arg, unsigned id);
/**
- * This enum indicates whether the master core must execute the handler
+ * This enum indicates whether the primary core must execute the handler
* launched on all logical cores.
*/
-enum rte_rmt_call_master_t {
- SKIP_MASTER = 0, /**< lcore handler not executed by master core. */
- CALL_MASTER, /**< lcore handler executed by master core. */
+enum rte_rmt_call_primary_t {
+ SKIP_PRIMARY = 0, /**< lcore handler not executed by primary core. */
+ CALL_PRIMARY, /**< lcore handler executed by primary core. */
};
/**
* Launch a function on all lcores.
*
- * Check that each SLAVE lcore is in a WAIT state, then call
+ * Check that each secondary lcore is in a WAIT state, then call
* rte_eal_remote_launch() for each lcore.
*
* @param f
* The function to be called.
* @param arg
* The argument for the function.
- * @param call_master
- * If call_master set to SKIP_MASTER, the MASTER lcore does not call
- * the function. If call_master is set to CALL_MASTER, the function
- * is also called on master before returning. In any case, the master
+ * @param call_primary
+ * If call_primary set to SKIP_PRIMARY, the PRIMARY lcore does not call
+ * the function. If call_primary is set to CALL_PRIMARY, the function
+ * is also called on primary before returning. In any case, the primary
* lcore returns as soon as it finished its job and knows nothing
* about the completion of f on the other lcores.
* @return
@@ -95,49 +95,49 @@ enum rte_rmt_call_master_t {
* case, no message is sent to any of the lcores.
*/
int rte_eal_mp_remote_launch(lcore_function_t *f, void *arg,
- enum rte_rmt_call_master_t call_master);
+ enum rte_rmt_call_primary_t call_primary);
/**
- * Get the state of the lcore identified by slave_id.
+ * Get the state of the lcore identified by id.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the PRIMARY lcore only.
*
- * @param slave_id
+ * @param id
* The identifier of the lcore.
* @return
* The state of the lcore.
*/
-enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned slave_id);
+enum rte_lcore_state_t rte_eal_get_lcore_state(unsigned id);
/**
* Wait until an lcore finishes its job.
*
- * To be executed on the MASTER lcore only.
+ * To be executed on the PRIMARY lcore only.
*
- * If the slave lcore identified by the slave_id is in a FINISHED state,
+ * If the lcore identified by the id is in a FINISHED state,
* switch to the WAIT state. If the lcore is in RUNNING state, wait until
* the lcore finishes its job and moves to the FINISHED state.
*
- * @param slave_id
+ * @param id
* The identifier of the lcore.
* @return
- * - 0: If the lcore identified by the slave_id is in a WAIT state.
+ * - 0: If the lcore identified by the id is in a WAIT state.
* - The value that was returned by the previous remote launch
- * function call if the lcore identified by the slave_id was in a
+ * function call if the lcore identified by the id was in a
* FINISHED or RUNNING state. In this case, it changes the state
* of the lcore to WAIT.
*/
-int rte_eal_wait_lcore(unsigned slave_id);
+int rte_eal_wait_lcore(unsigned id);
/**
* Wait until all lcores finish their jobs.
*
- * To be executed on the MASTER lcore only. Issue an
+ * To be executed on the PRIMARY lcore only. Issue an
* rte_eal_wait_lcore() for every lcore. The return values are
* ignored.
*
* After a call to rte_eal_mp_wait_lcore(), the caller can assume
- * that all slave lcores are in a WAIT state.
+ * that all secondary lcores are in a WAIT state.
*/
void rte_eal_mp_wait_lcore(void);
@@ -54,13 +54,21 @@ rte_lcore_id(void)
}
/**
- * Get the id of the master lcore
+ * Get the id of the primary lcore
*
* @return
- * the id of the master lcore
+ * the id of the primary lcore
*/
-unsigned int rte_get_master_lcore(void);
+unsigned int rte_get_primary_lcore(void);
+/**
+ * Deprecated API to get the id of the primary lcore
+ *
+ * @return
+ * the id of the primary lcore
+ */
+unsigned int rte_get_master_lcore(void) __rte_deprecated;
+
/**
* Return the number of execution units (lcores) on the system.
*
@@ -179,15 +187,15 @@ int rte_lcore_is_enabled(unsigned int lcore_id);
*
* @param i
* The current lcore (reference).
- * @param skip_master
- * If true, do not return the ID of the master lcore.
+ * @param skip_primary
+ * If true, do not return the ID of the primary lcore.
* @param wrap
* If true, go back to 0 when RTE_MAX_LCORE is reached; otherwise,
* return RTE_MAX_LCORE.
* @return
* The next lcore_id or RTE_MAX_LCORE if not found.
*/
-unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap);
+unsigned int rte_get_next_lcore(unsigned int i, int skip_primary, int wrap);
/**
* Macro to browse all running lcores.
@@ -198,13 +206,21 @@ unsigned int rte_get_next_lcore(unsigned int i, int skip_master, int wrap);
i = rte_get_next_lcore(i, 0, 0))
/**
- * Macro to browse all running lcores except the master lcore.
+ * Macro to browse all running lcores except the primary lcore.
*/
-#define RTE_LCORE_FOREACH_SLAVE(i) \
+#define RTE_LCORE_FOREACH_SECONDARY(i) \
for (i = rte_get_next_lcore(-1, 1, 0); \
i<RTE_MAX_LCORE; \
i = rte_get_next_lcore(i, 1, 0))
+/**
+ * Backword compatiablity
+ */
+#define RTE_LCORE_FOREACH_SLAVE(x) \
+ _Pragma("GCC warning \"'RTE_LCORE_FOREACH_SLAVE' macro is deprecated\"") \
+ RTE_LCORE_FOREACH_SECONDARY(x)
+
+
/**
* Set core affinity of the current thread.
* Support both EAL and non-EAL thread and update TLS.
@@ -879,7 +879,7 @@ eal_check_mem_on_local_socket(void)
{
int socket_id;
- socket_id = rte_lcore_to_socket_id(rte_config.master_lcore);
+ socket_id = rte_lcore_to_socket_id(rte_config.primary_lcore);
if (rte_memseg_list_walk(check_socket, &socket_id) == 0)
RTE_LOG(WARNING, EAL, "WARNING: Master core has no memory on local socket!\n");
@@ -1205,23 +1205,23 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
- eal_thread_init_master(rte_config.master_lcore);
+ eal_thread_init_primary(rte_config.primary_lcore);
ret = eal_thread_dump_affinity(cpuset, sizeof(cpuset));
RTE_LOG(DEBUG, EAL, "Master lcore %u is ready (tid=%zx;cpuset=[%s%s])\n",
- rte_config.master_lcore, (uintptr_t)thread_id, cpuset,
+ rte_config.primary_lcore, (uintptr_t)thread_id, cpuset,
ret == 0 ? "" : "...");
- RTE_LCORE_FOREACH_SLAVE(i) {
+ RTE_LCORE_FOREACH_SECONDARY(i) {
/*
- * create communication pipes between master thread
+ * create communication pipes between primary thread
* and children
*/
- if (pipe(lcore_config[i].pipe_master2slave) < 0)
+ if (pipe(lcore_config[i].pipe_primary2secondary) < 0)
rte_panic("Cannot create pipe\n");
- if (pipe(lcore_config[i].pipe_slave2master) < 0)
+ if (pipe(lcore_config[i].pipe_secondary2primary) < 0)
rte_panic("Cannot create pipe\n");
lcore_config[i].state = WAIT;
@@ -1234,7 +1234,7 @@ rte_eal_init(int argc, char **argv)
/* Set thread_name for aid in debugging. */
snprintf(thread_name, sizeof(thread_name),
- "lcore-slave-%d", i);
+ "lcore-secondary-%d", i);
ret = rte_thread_setname(lcore_config[i].thread_id,
thread_name);
if (ret != 0)