[dpdk-dev] [RFC] replace master/slave with primary/secondary

Wiles, Keith keith.wiles at intel.com
Fri Jun 5 22:09:23 CEST 2020



> On Jun 5, 2020, at 2:53 PM, Stephen Hemminger <stephen at networkplumber.org> wrote:
> 
> On Fri, 5 Jun 2020 19:23:52 +0000
> "Wiles, Keith" <keith.wiles at intel.com> wrote:
> 
>>> On Jun 5, 2020, at 12:45 PM, Stephen Hemminger <stephen at networkplumber.org> wrote:
>>> 
>>> On Fri, 5 Jun 2020 17:10:05 +0000
>>> "Wiles, Keith" <keith.wiles at 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



More information about the dev mailing list