Date   

Re: FD.io - Decommission OpenGrok Instance

Vanessa Valderrama
 

Reminder

On 7/14/20 2:47 PM, Vanessa Valderrama wrote:

What:  LF will decomission the FD.io OpenGrok instance

When:   2020-07-22 at 1700 UTC

Impact:  opengrok.fd.io will no longer be accessible

Why:  After reviewing our inventory it doesn't appear OpenGrok is being used by the community. We'll be shutting the service down as a cost saving effort.

Thank you,
Vanessa


Re: Coverage for 23rd and 30th of July

Zhang, Roy Fan <roy.fan.zhang@...>
 

Hi Ed,

 

Thanks! It’s my honor. Looking forward to meeting everybody too!

 

Regards,

Fan

 

From: Ed Warnicke <hagbard@...>
Sent: Friday, July 17, 2020 8:22 PM
To: Kinsella, Ray <ray.kinsella@...>
Cc: tsc@...; Zhang, Roy Fan <roy.fan.zhang@...>; DiGiglio, John <john.digiglio@...>
Subject: Re: [tsc] Coverage for 23rd and 30th of July

 

Fan,

 

Delighted to have you!  Look forward to seeing you at the TSC :)

 

Ed

 

On Fri, Jul 17, 2020 at 8:33 AM Ray Kinsella <ray.kinsella@...> wrote:

Hi Ed,

 

I am OOO on staycation for the next two weeks.

My colleague Fan Zhang has agreed to cover the TSC on behalf of Intel.

 

Fan is regular contributor to both FD.io VPP and DPDK, please welcome him.

 

Thanks,

 

Ray K


Re: Coverage for 23rd and 30th of July

Edward Warnicke
 

Fan,

Delighted to have you!  Look forward to seeing you at the TSC :)

Ed

On Fri, Jul 17, 2020 at 8:33 AM Ray Kinsella <ray.kinsella@...> wrote:

Hi Ed,

 

I am OOO on staycation for the next two weeks.

My colleague Fan Zhang has agreed to cover the TSC on behalf of Intel.

 

Fan is regular contributor to both FD.io VPP and DPDK, please welcome him.

 

Thanks,

 

Ray K



Coverage for 23rd and 30th of July

Ray Kinsella
 

Hi Ed,

 

I am OOO on staycation for the next two weeks.

My colleague Fan Zhang has agreed to cover the TSC on behalf of Intel.

 

Fan is regular contributor to both FD.io VPP and DPDK, please welcome him.

 

Thanks,

 

Ray K


REMINDER: Input Due July 24: Annual LFN Operations Survey

Brandon Wick
 

LFN Communities:

For the second year, LF Networking staff have pulled together an LFN Operations Survey, AKA "staff survey of the community." The goal is to solicit feedback from LFN community members to learn how you are engaging with projects, what you are experiencing, what the challenges are, and how the LFN staff can better support you. Your feedback is very important so please take a few minutes to share your thoughts with us. Responses are due by Friday, July 24th

Best,

Brandon Wick
Senior Integrated Marketing Manager
The Linux Foundation
+1.917.282.0960


Re: [vpp-dev] Replacing master/slave nomenclature

Edward Warnicke
 

In today's TSC meeting we had a discussion of what, if any, role the TSC should play in the renaming process around nomenclatures like master/slave whitelist/blacklist etc.

It's important to understand that the TSC in FD.io, quite intentionally, does not and cannot tell the projects what to do.  Given that, and the fact that there are technical details involved in making the proper renaming decisions, we determined that there are two potentially helpful things we can and do:

1)  Attempt to assemble helpful guidance to projects in making their decisions.  This would include pointing out resources for alternate name ideas, considerations like coordination with neighboring communities and standards bodies that may also be renaming to attempt to achieve consistency etc.

2)  Provide a publicly facing visible reporting of what various FD.io projects are doing around renaming.  Some renaming is going to involve API changes that take time to responsibly implement.  Some renaming will involve consensus seeking with other communities and standards bodies.  We want to make clear that we are taking this seriously, taking action, and provide public visibility into the process.  As with most things in Open Source, visibility and openness are the best medicine.

The TSC is also quite interested in input from the broader community about what we could productively do, suggestions or comments around the current thoughts, and participation from those who wish to be more involved in solving these problems.

Ed



On Tue, Jul 14, 2020 at 1:15 PM Ed Warnicke <hagbard@...> wrote:
I tend to prefer permitlist/denylist personally... but I may have configured one too many ACLs in my life...

Ed

On Tue, Jul 14, 2020 at 12:49 PM Christian Hopps <chopps@...> wrote:


> On Jul 14, 2020, at 1:20 PM, St Leger, Jim <jim.st.leger@...> wrote:
>
> I believe the DPDK community converged on:
> master/slave lcore -> initial/worker lcore

VPP is ok here I think with "main" and "worker".

> blacklist/whitelist -> blocklist/allowlist

That one feels a bit clunky to me. I wonder why they didn't go for something more natural like

  nouns: blocked/allowed
  verbs: block/allow

The terms blacklist/whitelist can be a nouns or verbs, and I suspect they are often not implemented as an actual list data structure, so trying to keep the "list" suffix seems an unnecessary carryover (and sounds clunky IMHO). :)

Thanks,
Chris.

>
> Full community discussion: https://mails.dpdk.org/archives/dev/2020-June/thread.html#169337
>
> Jim
>
> -----Original Message-----
> From: vpp-dev@... <vpp-dev@...> On Behalf Of Jerome Tollet via lists.fd.io
> Sent: Tuesday, July 14, 2020 10:10 AM
> To: Chris Luke <chris_luke@...>; Steven Luong (sluong) <sluong@...>; Dave Barach (dbarach) <dbarach@...>; Kinsella, Ray <mdr@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
> Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature
>
> Hi Chris,
> I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO.
> Jerome
>
> Le 14/07/2020 18:45, « tsc@... au nom de Chris Luke » <tsc@... au nom de chris_luke@...> a écrit :
>
>    It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?
>
>    Chris.
>
>    -----Original Message-----
>    From: vpp-dev@... <vpp-dev@...> On Behalf Of Jerome Tollet via lists.fd.io
>    Sent: Tuesday, July 14, 2020 12:37
>    To: Steven Luong (sluong) <sluong@...>; Dave Barach (dbarach) <dbarach@...>; Kinsella, Ray <mdr@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
>    Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature
>
>    Hi Steven,
>    Please note that per this proposition,  https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
>    Maybe master/member or master/secondary could be options too.
>    Jerome
>
>    Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :
>
>        I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.
>
>        Steven
>
>        On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:
>
>            +1, especially since our next release will be supported for a year, and API name changes are involved...
>
>            -----Original Message-----
>            From: Kinsella, Ray <mdr@...>
>            Sent: Monday, July 13, 2020 6:01 AM
>            To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
>            Subject: Re: [vpp-dev] Replacing master/slave nomenclature
>
>            Hi Stephen,
>
>            I agree, I don't think we should ignore this.
>            Ed - I suggest we table a discussion at the next FD.io TSC?
>
>            Ray K
>
>            On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
>> Looping in the technical steering committee...
>>
>> -----Original Message-----
>> From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
>> Sent: Thursday, July 2, 2020 7:02 PM
>> To: vpp-dev@...
>> Subject: [vpp-dev] Replacing master/slave nomenclature
>>
>> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>>
>> Particularly problematic is the use of master/slave in bonding.
>> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>>
>> The IEEE and IETF are doing an across the board look at these terms in standards.
>>
>>
>>
>>
>
>
>
>



Re: [vpp-dev] Published: FD.io CSIT-2005 Release Report

Jerome Tollet
 

Hi Maciek,
Very impressive report with some interesting performance boosts. Thanks!
Jerome

Le 14/07/2020 15:33, « vpp-dev@lists.fd.io au nom de Maciek Konstantynowicz (mkonstan) via lists.fd.io » <vpp-dev@lists.fd.io au nom de mkonstan=cisco.com@lists.fd.io> a écrit :

Hi All,

FD.io CSIT-2005 report has been published on FD.io docs site:

https://docs.fd.io/csit/rls2005/report/

Many thanks to All in CSIT, VPP and wider FD.io community who
contributed and worked hard to make CSIT-2005 happen!

See below for pointers to specific sections in the report.

Welcome all comments, best by email to csit-dev@lists.fd.io.

Cheers,
-Maciek

------------------------------------------------------------------------
Points of Note in the CSIT-2005 Report
------------------------------------------------------------------------
Indexed specific links listed at the bottom.

1. VPP release notes
a. Changes in CSIT-2005: [1]
b. Known issues: [2]

2. VPP performance - 64B/IMIX throughput graphs (selected NIC models):
a. Graphs explained: [3]
b. L2 Ethernet Switching: [4]
c. IPv4 Routing: [5]
d. IPv6 Routing: [6]
e. SRv6 Routing: [7]
f. IPv4 Tunnels: [8]
g. KVM VMs vhost-user: [9]
h. LXC/DRC Container Memif: [10]
e. IPsec IPv4 Routing: [11]
f. Virtual Topology System: [12]

3. VPP performance - multi-core and latency graphs:
a. Speedup Multi-Core: [13]
b. Latency: [14]

4. VPP performance comparisons
a. VPP-20.05 vs. VPP-20.01: [15]

5. VPP performance test details - all NICs:
a. Detailed results 64B IMIX 1518B 9kB: [16]
b. Configuration: [17]

DPDK Testpmd and L3fwd performance sections follow similar structure.

6. DPDK applications:
a. Release notes: [18]
b. DPDK performance - 64B throughput graphs: [19]
c. DPDK performance - latency graphs: [20]
d. DPDK performance - DPDK-20.02 vs. DPDK-19.08: [21]

Functional device tests (VPP_Device) are also included in the report.

Specific links within the report:

[1] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release
[2] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#known-issues
[3] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/index.html
[4] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/l2.html
[5] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4.html
[6] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip6.html
[7] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/srv6.html
[8] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4_tunnels.html
[9] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vm_vhost.html
[10] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/container_memif.html
[11] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ipsec.html
[12] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vts.html
[13] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/throughput_speedup_multi_core/index.html
[14] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_latency/index.html
[15] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/comparisons/current_vs_previous_release.html
[16] https://docs.fd.io/csit/rls2005/report/detailed_test_results/vpp_performance_results/index.html
[17] https://docs.fd.io/csit/rls2005/report/test_configuration/vpp_performance_configuration/index.html
[18] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/csit_release_notes.html
[19] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_throughput_graphs/index.html
[20] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_latency/index.html
[21] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html
------------------------------------------------------------------------


FD.io - Decommission OpenGrok Instance

Vanessa Valderrama
 

What:  LF will decomission the FD.io OpenGrok instance

When:   2020-07-22 at 1700 UTC

Impact:  opengrok.fd.io will no longer be accessible

Why:  After reviewing our inventory it doesn't appear OpenGrok is being used by the community. We'll be shutting the service down as a cost saving effort.

Thank you,
Vanessa


FD.io - Decommission SonarQube Instance

Vanessa Valderrama
 

What:  LF will decomission the FD.io SonarQue instance

When:   2020-07-22 at 1700 UTC

Impact:  sonar.fd.io and code quality reports and history will no longer be accessible

Why:  LF has migrated to SonarCloud. All FD.io project yaml files have been configured for SonarCloud jobs.

Thank you,
Vanessa


Re: [vpp-dev] Replacing master/slave nomenclature

Steven Luong (sluong) <sluong@...>
 

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>


Re: [vpp-dev] Published: FD.io CSIT-2005 Release Report

Andrew 👽 Yourtchenko <ayourtch@...>
 

Congrats! That was an excellent job done !

--a

On 14 Jul 2020, at 15:33, Maciek Konstantynowicz (mkonstan) via lists.fd.io <mkonstan=cisco.com@lists.fd.io> wrote:

Hi All,

FD.io CSIT-2005 report has been published on FD.io docs site:

https://docs.fd.io/csit/rls2005/report/

Many thanks to All in CSIT, VPP and wider FD.io community who
contributed and worked hard to make CSIT-2005 happen!

See below for pointers to specific sections in the report.

Welcome all comments, best by email to csit-dev@lists.fd.io.

Cheers,
-Maciek

------------------------------------------------------------------------
Points of Note in the CSIT-2005 Report
------------------------------------------------------------------------
Indexed specific links listed at the bottom.

1. VPP release notes
a. Changes in CSIT-2005: [1]
b. Known issues: [2]

2. VPP performance - 64B/IMIX throughput graphs (selected NIC models):
a. Graphs explained: [3]
b. L2 Ethernet Switching: [4]
c. IPv4 Routing: [5]
d. IPv6 Routing: [6]
e. SRv6 Routing: [7]
f. IPv4 Tunnels: [8]
g. KVM VMs vhost-user: [9]
h. LXC/DRC Container Memif: [10]
e. IPsec IPv4 Routing: [11]
f. Virtual Topology System: [12]

3. VPP performance - multi-core and latency graphs:
a. Speedup Multi-Core: [13]
b. Latency: [14]

4. VPP performance comparisons
a. VPP-20.05 vs. VPP-20.01: [15]

5. VPP performance test details - all NICs:
a. Detailed results 64B IMIX 1518B 9kB: [16]
b. Configuration: [17]

DPDK Testpmd and L3fwd performance sections follow similar structure.

6. DPDK applications:
a. Release notes: [18]
b. DPDK performance - 64B throughput graphs: [19]
c. DPDK performance - latency graphs: [20]
d. DPDK performance - DPDK-20.02 vs. DPDK-19.08: [21]

Functional device tests (VPP_Device) are also included in the report.

Specific links within the report:

[1] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#changes-in-csit-release
[2] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/csit_release_notes.html#known-issues
[3] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/index.html
[4] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/l2.html
[5] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4.html
[6] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip6.html
[7] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/srv6.html
[8] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ip4_tunnels.html
[9] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vm_vhost.html
[10] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/container_memif.html
[11] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/ipsec.html
[12] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_throughput_graphs/vts.html
[13] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/throughput_speedup_multi_core/index.html
[14] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/packet_latency/index.html
[15] https://docs.fd.io/csit/rls2005/report/vpp_performance_tests/comparisons/current_vs_previous_release.html
[16] https://docs.fd.io/csit/rls2005/report/detailed_test_results/vpp_performance_results/index.html
[17] https://docs.fd.io/csit/rls2005/report/test_configuration/vpp_performance_configuration/index.html
[18] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/csit_release_notes.html
[19] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_throughput_graphs/index.html
[20] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/packet_latency/index.html
[21] https://docs.fd.io/csit/rls2005/report/dpdk_performance_tests/comparisons/current_vs_previous_release.html
------------------------------------------------------------------------


Re: [vpp-dev] Replacing master/slave nomenclature

Christian Hopps <chopps@...>
 

On Jul 14, 2020, at 1:20 PM, St Leger, Jim <jim.st.leger@intel.com> wrote:

I believe the DPDK community converged on:
master/slave lcore -> initial/worker lcore
VPP is ok here I think with "main" and "worker".

blacklist/whitelist -> blocklist/allowlist
That one feels a bit clunky to me. I wonder why they didn't go for something more natural like

nouns: blocked/allowed
verbs: block/allow

The terms blacklist/whitelist can be a nouns or verbs, and I suspect they are often not implemented as an actual list data structure, so trying to keep the "list" suffix seems an unnecessary carryover (and sounds clunky IMHO). :)

Thanks,
Chris.


Full community discussion: https://mails.dpdk.org/archives/dev/2020-June/thread.html#169337

Jim

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 10:10 AM
To: Chris Luke <chris_luke@comcast.com>; Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

Hi Chris,
I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO.
Jerome

Le 14/07/2020 18:45, « tsc@lists.fd.io au nom de Chris Luke » <tsc@lists.fd.io au nom de chris_luke@comcast.com> a écrit :

It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?

Chris.

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 12:37
To: Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven,
Please note that per this proposition, https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » <vpp-dev@lists.fd.io au nom de sluong=cisco.com@lists.fd.io> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
Looping in the technical steering committee...

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
Sent: Thursday, July 2, 2020 7:02 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Replacing master/slave nomenclature

Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.

Particularly problematic is the use of master/slave in bonding.
This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.

The IEEE and IETF are doing an across the board look at these terms in standards.






Re: [vpp-dev] Replacing master/slave nomenclature

Steven Luong (sluong) <sluong@...>
 

The list has a good number of suggestions. In 802.1ax spec, they use the term aggregator and member link. So I am inclined to stick to aggregator/member unless someone finds that it is unacceptable.

 

Steven

 

From: Ed Warnicke <hagbard@...>
Date: Tuesday, July 14, 2020 at 9:45 AM
To: "Jerome Tollet (jtollet)" <jtollet@...>
Cc: "Steven Luong (sluong)" <sluong@...>, "Dave Barach (dbarach)" <dbarach@...>, "Kinsella, Ray" <mdr@...>, Stephen Hemminger <stephen@...>, "vpp-dev@..." <vpp-dev@...>, "tsc@..." <tsc@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

 

This is a pretty good summary of various suggestions for replacement terms:

 

 

Ed

 

On Tue, Jul 14, 2020 at 11:36 AM Jerome Tollet via lists.fd.io <jtollet=cisco.com@...> wrote:

Hi Steven,
Please note that per this proposition,  https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :

    I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

    Steven

    On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:

        +1, especially since our next release will be supported for a year, and API name changes are involved...

        -----Original Message-----
        From: Kinsella, Ray <mdr@...>
        Sent: Monday, July 13, 2020 6:01 AM
        To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
        Subject: Re: [vpp-dev] Replacing master/slave nomenclature

        Hi Stephen,

        I agree, I don't think we should ignore this.
        Ed - I suggest we table a discussion at the next FD.io TSC?

        Ray K

        On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
        > Looping in the technical steering committee...
        >
        > -----Original Message-----
        > From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
        > Sent: Thursday, July 2, 2020 7:02 PM
        > To: vpp-dev@...
        > Subject: [vpp-dev] Replacing master/slave nomenclature
        >
        > Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
        >
        > Particularly problematic is the use of master/slave in bonding.
        > This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
        >
        > The IEEE and IETF are doing an across the board look at these terms in standards.
        >
        >
        >
        >



Re: [vpp-dev] Replacing master/slave nomenclature

Edward Warnicke
 

I tend to prefer permitlist/denylist personally... but I may have configured one too many ACLs in my life...

Ed

On Tue, Jul 14, 2020 at 12:49 PM Christian Hopps <chopps@...> wrote:


> On Jul 14, 2020, at 1:20 PM, St Leger, Jim <jim.st.leger@...> wrote:
>
> I believe the DPDK community converged on:
> master/slave lcore -> initial/worker lcore

VPP is ok here I think with "main" and "worker".

> blacklist/whitelist -> blocklist/allowlist

That one feels a bit clunky to me. I wonder why they didn't go for something more natural like

  nouns: blocked/allowed
  verbs: block/allow

The terms blacklist/whitelist can be a nouns or verbs, and I suspect they are often not implemented as an actual list data structure, so trying to keep the "list" suffix seems an unnecessary carryover (and sounds clunky IMHO). :)

Thanks,
Chris.

>
> Full community discussion: https://mails.dpdk.org/archives/dev/2020-June/thread.html#169337
>
> Jim
>
> -----Original Message-----
> From: vpp-dev@... <vpp-dev@...> On Behalf Of Jerome Tollet via lists.fd.io
> Sent: Tuesday, July 14, 2020 10:10 AM
> To: Chris Luke <chris_luke@...>; Steven Luong (sluong) <sluong@...>; Dave Barach (dbarach) <dbarach@...>; Kinsella, Ray <mdr@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
> Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature
>
> Hi Chris,
> I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO.
> Jerome
>
> Le 14/07/2020 18:45, « tsc@... au nom de Chris Luke » <tsc@... au nom de chris_luke@...> a écrit :
>
>    It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?
>
>    Chris.
>
>    -----Original Message-----
>    From: vpp-dev@... <vpp-dev@...> On Behalf Of Jerome Tollet via lists.fd.io
>    Sent: Tuesday, July 14, 2020 12:37
>    To: Steven Luong (sluong) <sluong@...>; Dave Barach (dbarach) <dbarach@...>; Kinsella, Ray <mdr@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
>    Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature
>
>    Hi Steven,
>    Please note that per this proposition,  https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
>    Maybe master/member or master/secondary could be options too.
>    Jerome
>
>    Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :
>
>        I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.
>
>        Steven
>
>        On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:
>
>            +1, especially since our next release will be supported for a year, and API name changes are involved...
>
>            -----Original Message-----
>            From: Kinsella, Ray <mdr@...>
>            Sent: Monday, July 13, 2020 6:01 AM
>            To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
>            Subject: Re: [vpp-dev] Replacing master/slave nomenclature
>
>            Hi Stephen,
>
>            I agree, I don't think we should ignore this.
>            Ed - I suggest we table a discussion at the next FD.io TSC?
>
>            Ray K
>
>            On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
>> Looping in the technical steering committee...
>>
>> -----Original Message-----
>> From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
>> Sent: Thursday, July 2, 2020 7:02 PM
>> To: vpp-dev@...
>> Subject: [vpp-dev] Replacing master/slave nomenclature
>>
>> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>>
>> Particularly problematic is the use of master/slave in bonding.
>> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>>
>> The IEEE and IETF are doing an across the board look at these terms in standards.
>>
>>
>>
>>
>
>
>
>



Re: [vpp-dev] Replacing master/slave nomenclature

St Leger, Jim
 

I believe the DPDK community converged on:
master/slave lcore -> initial/worker lcore
blacklist/whitelist -> blocklist/allowlist

Full community discussion: https://mails.dpdk.org/archives/dev/2020-June/thread.html#169337

Jim

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 10:10 AM
To: Chris Luke <chris_luke@comcast.com>; Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

Hi Chris,
I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO.
Jerome

Le 14/07/2020 18:45, « tsc@lists.fd.io au nom de Chris Luke » <tsc@lists.fd.io au nom de chris_luke@comcast.com> a écrit :

It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?

Chris.

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 12:37
To: Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven,
Please note that per this proposition, https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » <vpp-dev@lists.fd.io au nom de sluong=cisco.com@lists.fd.io> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>


Re: [vpp-dev] Replacing master/slave nomenclature

Jerome Tollet
 

Hi Chris,
I suspect it would be good to align on the new bond nomenclature coming from other projects. DPDK and Linux are probably starting points we should consider IMO.
Jerome

Le 14/07/2020 18:45, « tsc@lists.fd.io au nom de Chris Luke » <tsc@lists.fd.io au nom de chris_luke@comcast.com> a écrit :

It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?

Chris.

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 12:37
To: Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven,
Please note that per this proposition, https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » <vpp-dev@lists.fd.io au nom de sluong=cisco.com@lists.fd.io> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>


Re: [vpp-dev] Replacing master/slave nomenclature

Edward Warnicke
 

Steven,

That sounds good to me.  I tend to see this as "Get the good ideas for possible replacements out there so the folks doing the work have some inspiration for the choices".  Please don't take the link as suggesting that list is the end all and be all of possible choices :)

Ed

On Tue, Jul 14, 2020 at 11:54 AM Steven Luong (sluong) <sluong@...> wrote:

The list has a good number of suggestions. In 802.1ax spec, they use the term aggregator and member link. So I am inclined to stick to aggregator/member unless someone finds that it is unacceptable.

 

Steven

 

From: Ed Warnicke <hagbard@...>
Date: Tuesday, July 14, 2020 at 9:45 AM
To: "Jerome Tollet (jtollet)" <jtollet@...>
Cc: "Steven Luong (sluong)" <sluong@...>, "Dave Barach (dbarach)" <dbarach@...>, "Kinsella, Ray" <mdr@...>, Stephen Hemminger <stephen@...>, "vpp-dev@..." <vpp-dev@...>, "tsc@..." <tsc@...>, "Ed Warnicke (eaw)" <eaw@...>
Subject: Re: [tsc] [vpp-dev] Replacing master/slave nomenclature

 

This is a pretty good summary of various suggestions for replacement terms:

 

 

Ed

 

On Tue, Jul 14, 2020 at 11:36 AM Jerome Tollet via lists.fd.io <jtollet=cisco.com@...> wrote:

Hi Steven,
Please note that per this proposition,  https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :

    I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

    Steven

    On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:

        +1, especially since our next release will be supported for a year, and API name changes are involved...

        -----Original Message-----
        From: Kinsella, Ray <mdr@...>
        Sent: Monday, July 13, 2020 6:01 AM
        To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
        Subject: Re: [vpp-dev] Replacing master/slave nomenclature

        Hi Stephen,

        I agree, I don't think we should ignore this.
        Ed - I suggest we table a discussion at the next FD.io TSC?

        Ray K

        On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
        > Looping in the technical steering committee...
        >
        > -----Original Message-----
        > From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
        > Sent: Thursday, July 2, 2020 7:02 PM
        > To: vpp-dev@...
        > Subject: [vpp-dev] Replacing master/slave nomenclature
        >
        > Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
        >
        > Particularly problematic is the use of master/slave in bonding.
        > This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
        >
        > The IEEE and IETF are doing an across the board look at these terms in standards.
        >
        >
        >
        >



Re: [vpp-dev] Replacing master/slave nomenclature

Chris Luke
 

It is subjective and contextualized. But in this case, if making the effort to correct a wrong, why stop half way?

Chris.

-----Original Message-----
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome Tollet via lists.fd.io
Sent: Tuesday, July 14, 2020 12:37
To: Steven Luong (sluong) <sluong@cisco.com>; Dave Barach (dbarach) <dbarach@cisco.com>; Kinsella, Ray <mdr@ashroe.eu>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: [EXTERNAL] Re: [vpp-dev] Replacing master/slave nomenclature

Hi Steven,
Please note that per this proposition, https://urldefense.com/v3/__https://lkml.org/lkml/2020/7/4/229__;!!CQl3mcHX2A!QdLdxm4rtZW-mFe5jt_qzEpx-_X2KWnqvjyEl-7Py41jsEV7FrnEw0lTNcF8LdfUzQ$ , slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » <vpp-dev@lists.fd.io au nom de sluong=cisco.com@lists.fd.io> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>


Re: [vpp-dev] Replacing master/slave nomenclature

Edward Warnicke
 

This is a pretty good summary of various suggestions for replacement terms:


Ed

On Tue, Jul 14, 2020 at 11:36 AM Jerome Tollet via lists.fd.io <jtollet=cisco.com@...> wrote:
Hi Steven,
Please note that per this proposition,  https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@... au nom de steven luong via lists.fd.io » <vpp-dev@... au nom de sluong=cisco.com@...> a écrit :

    I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

    Steven

    On 7/13/20, 4:44 AM, "vpp-dev@... on behalf of Dave Barach via lists.fd.io" <vpp-dev@... on behalf of dbarach=cisco.com@...> wrote:

        +1, especially since our next release will be supported for a year, and API name changes are involved...

        -----Original Message-----
        From: Kinsella, Ray <mdr@...>
        Sent: Monday, July 13, 2020 6:01 AM
        To: Dave Barach (dbarach) <dbarach@...>; Stephen Hemminger <stephen@...>; vpp-dev@...; tsc@...; Ed Warnicke (eaw) <eaw@...>
        Subject: Re: [vpp-dev] Replacing master/slave nomenclature

        Hi Stephen,

        I agree, I don't think we should ignore this.
        Ed - I suggest we table a discussion at the next FD.io TSC?

        Ray K

        On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
        > Looping in the technical steering committee...
        >
        > -----Original Message-----
        > From: vpp-dev@... <vpp-dev@...> On Behalf Of Stephen Hemminger
        > Sent: Thursday, July 2, 2020 7:02 PM
        > To: vpp-dev@...
        > Subject: [vpp-dev] Replacing master/slave nomenclature
        >
        > Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI?  We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
        >
        > Particularly problematic is the use of master/slave in bonding.
        > This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
        >
        > The IEEE and IETF are doing an across the board look at these terms in standards.
        >
        >
        >
        >




Re: [vpp-dev] Replacing master/slave nomenclature

Jerome Tollet
 

Hi Steven,
Please note that per this proposition, https://lkml.org/lkml/2020/7/4/229, slave must be avoided but master can be kept.
Maybe master/member or master/secondary could be options too.
Jerome

Le 14/07/2020 18:32, « vpp-dev@lists.fd.io au nom de steven luong via lists.fd.io » <vpp-dev@lists.fd.io au nom de sluong=cisco.com@lists.fd.io> a écrit :

I am in the process of pushing a patch to replace master/slave with aggregator/member for the bonding.

Steven

On 7/13/20, 4:44 AM, "vpp-dev@lists.fd.io on behalf of Dave Barach via lists.fd.io" <vpp-dev@lists.fd.io on behalf of dbarach=cisco.com@lists.fd.io> wrote:

+1, especially since our next release will be supported for a year, and API name changes are involved...

-----Original Message-----
From: Kinsella, Ray <mdr@ashroe.eu>
Sent: Monday, July 13, 2020 6:01 AM
To: Dave Barach (dbarach) <dbarach@cisco.com>; Stephen Hemminger <stephen@networkplumber.org>; vpp-dev@lists.fd.io; tsc@lists.fd.io; Ed Warnicke (eaw) <eaw@cisco.com>
Subject: Re: [vpp-dev] Replacing master/slave nomenclature

Hi Stephen,

I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?

Ray K

On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering committee...
>
> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Stephen Hemminger
> Sent: Thursday, July 2, 2020 7:02 PM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Replacing master/slave nomenclature
>
> Is the VPP project addressing the use of master/slave nomenclature in the code base, documentation and CLI? We are doing this for DPDK and it would be good if the replacement wording used in DPDK matched the wording used in FD.io projects.
>
> Particularly problematic is the use of master/slave in bonding.
> This seems to be a leftover from Linux, since none of the commercial products use that terminology and it is not present in 802.1AX standard.
>
> The IEEE and IETF are doing an across the board look at these terms in standards.
>
>
>
>

181 - 200 of 1552