Aligning DPDK Link bonding with current standards terminology

dpdk-dev Stephen Hemminger 3 participants 6 messages Jun 15, 2020 – Jun 16, 2020

Share & tools

Stephen Hemminger

author

2020-06-15 22:52 UTC #0 lore raw

I am disturbed by the wide spread use of master/slave in Ethernet bonding. Asked the current IEEE chairs and it looks like it is already fixed "upstream".

The proper terminology is for Ethernet link aggregation in the
the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and "Protocol multiplexer".

Also it is not called bonding anywhere; it uses LACP only.

Given the large scope of the name changes. Maybe it would be best to just convert the names all of rte_eth_bond to rte_eth_lacp and fix the master/slave references at the same time.

For one brief release (20.08) keep both drivers and mark the bond on as deprecated. It would also help if all the documentation and tests were checked to see if they align with the current standard.

Chas Williams

2020-06-16 10:03 UTC #1 lore raw

Quoted 7 lines · Stephen Hemminger

I am disturbed by the wide spread use of master/slave in Ethernet bonding. Asked the current IEEE chairs and it looks like it is already fixed "upstream".
The proper terminology is for Ethernet link aggregation in the
the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and "Protocol multiplexer".

Quoted 9 lines

Also it is not called bonding anywhere; it uses LACP only.
Given the large scope of the name changes. Maybe it would be best to just convert the names all of rte_eth_bond to rte_eth_lacp and fix the master/slave references at the same time.
For one brief release (20.08) keep both drivers and mark the bond on as deprecated. It would also help if all the documentation and tests were checked to see if they align with the current standard.

However, the bonding driver supports more than just the LACP protocol for managing members of a bond group. I suggest renaming the existing API that is objectionable and providing the old names for one release. I will see if I can get a copy of the 802.1AX 2020 revision.

Jay Rolette

2020-06-16 11:48 UTC #2 lore raw

In reply to Stephen Hemminger

Quoted 11 lines · Stephen Hemminger

I am disturbed by the wide spread use of master/slave in Ethernet bonding. Asked the current IEEE chairs and it looks like it is already fixed "upstream".
The proper terminology is for Ethernet link aggregation in the the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and "Protocol multiplexer".
Also it is not called bonding anywhere; it uses LACP only.

LACP is only 1 of 5 bonding modes.

Quoted 5 lines

Given the large scope of the name changes. Maybe it would be best to just convert the names
all of rte_eth_bond to rte_eth_lacp and fix the master/slave references at the same time.

Why rename rte_eth_bond at all?

Quoted 6 lines

For one brief release (20.08) keep both drivers and mark the bond on as deprecated.
It would also help if all the documentation and tests were checked to see if they
align with the current standard.

The current naming appears to be a straight copy of the Linux naming + a prefix change.

Chas Williams

2020-06-16 13:52 UTC #3 lore raw

Quoted 18 lines · Jay Rolette

Quoted 11 lines · Stephen Hemminger
I am disturbed by the wide spread use of master/slave in Ethernet bonding. Asked the current IEEE chairs and it looks like it is already fixed "upstream".
The proper terminology is for Ethernet link aggregation in the the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and "Protocol multiplexer".
Also it is not called bonding anywhere; it uses LACP only.
LACP is only 1 of 5 bonding modes.

Quoted 7 lines

Quoted 5 lines
Given the large scope of the name changes. Maybe it would be best to just convert the names
all of rte_eth_bond to rte_eth_lacp and fix the master/slave references at the same time.
Why rename rte_eth_bond at all?

If there is a strong desire to rename the PMD, I suggest using link aggregration group (LAG/lag) since that is a more accurate description of this feature. That's the terminology used in 802.1AX. This would make some of the internal name changes more natural as well.

Quoted 12 lines

Quoted 8 lines
For one brief release (20.08) keep both drivers and mark the bond on as deprecated.
It would also help if all the documentation and tests were checked to see if they
align with the current standard.
The current naming appears to be a straight copy of the Linux naming + a prefix change.

Stephen Hemminger

author

2020-06-16 15:45 UTC #4 lore raw

Quoted 29 lines · On Tue, 16 Jun 2020 09:52:01 -0400 Chas Williams <[email protected]> wrote:

Quoted 4 lines · Jay Rolette
Quoted 1 line · Stephen Hemminger
I am disturbed by the wide spread use of master/slave in Ethernet
bonding.
Quoted 6 lines
Quoted 6 lines
Asked the current IEEE chairs and it looks like it is already fixed "upstream".
The proper terminology is for Ethernet link aggregation in the the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and
"Protocol
Quoted 9 lines
Quoted 4 lines
multiplexer".
Also it is not called bonding anywhere; it uses LACP only.
LACP is only 1 of 5 bonding modes.
Quoted 1 line
Given the large scope of the name changes. Maybe it would be best to
just
Quoted 2 lines
Quoted 2 lines
convert the names
all of rte_eth_bond to rte_eth_lacp and fix the master/slave
references at
Quoted 3 lines
Quoted 2 lines
the same time.

Quoted 6 lines

Quoted 1 line
Why rename rte_eth_bond at all?
If there is a strong desire to rename the PMD, I suggest using link aggregration group (LAG/lag) since that is a more accurate description of this feature. That's the terminology used in 802.1AX. This would make some of the internal name changes more natural as well.

The words that matter most are getting rid of master/slave and blacklist/whitelist. The worst is "bonded slave". Luckily the master and slave are only used internally in the driver so no visible API/ABI with those terms.

One option would be to substitute slave with multiplexer in the comments and shorter term like mux in the variables. And replace master with aggregator.

You are right, the standard name is LACP other names seem to be viewed as early history alternatives:
Cisco - Etherchannel
Juniper - Aggregated Ethernet
Others - Multi-link
BSD - lagg
Linux bonding
Solaris aggr

The point of this thread is to get consensus about best future naming.

Chas Williams

2020-06-16 20:27 UTC #5 lore raw

Quoted 34 lines · Stephen Hemminger

Quoted 31 lines · On Tue, 16 Jun 2020 09:52:01 -0400 Chas Williams <[email protected]> wrote:
Quoted 4 lines · Jay Rolette
Quoted 1 line · Stephen Hemminger
I am disturbed by the wide spread use of master/slave in Ethernet
bonding.
Quoted 6 lines
Quoted 6 lines
Asked the current IEEE chairs and it looks like it is already fixed "upstream".
The proper terminology is for Ethernet link aggregation in the the current standard 802.1AX 2020 revision (pay walled) for the parts formerly known as master and slave is now "Protocol Parser" and
"Protocol
Quoted 9 lines
Quoted 4 lines
multiplexer".
Also it is not called bonding anywhere; it uses LACP only.
LACP is only 1 of 5 bonding modes.
Quoted 1 line
Given the large scope of the name changes. Maybe it would be best to
just
Quoted 2 lines
Quoted 2 lines
convert the names
all of rte_eth_bond to rte_eth_lacp and fix the master/slave
references at
Quoted 4 lines
Quoted 2 lines
the same time.
Why rename rte_eth_bond at all?

Quoted 7 lines

Quoted 4 lines
If there is a strong desire to rename the PMD, I suggest using link aggregration group (LAG/lag) since that is a more accurate description of this feature. That's the terminology used in 802.1AX. This would make some of the internal name changes more natural as well.
The words that matter most are getting rid of master/slave and blacklist/whitelist. The worst is "bonded slave". Luckily the master and slave are only used internally

After looking at the specification, I might suggest renaming slaves to links. Member would likely be fine as well if one is concerned about confusion with link status. As for the container name, aggregator or aggregate would be fine. aggport would be closer to the specification.

Quoted 1 line

in the driver so no visible API/ABI with those terms.

I am not entirely convinced of that.

% egrep -i 'master|slave' rte_pmd_bond_version.map

	rte_eth_bond_8023ad_slave_info;
	rte_eth_bond_active_slaves_get;
	rte_eth_bond_slave_add;
	rte_eth_bond_slave_remove;
	rte_eth_bond_slaves_get;

Quoted 2 lines

One option would be to substitute slave with multiplexer in the comments and shorter term like mux in the variables. And replace master with aggregator.

There are very few master references in the bonding PMD. It's usage appears to be as an adjective and easily removed. The "master" port is typically called bonded which isn't fantastic since bond is often used in a slightly different context.

Quoted 11 lines

You are right, the standard name is LACP other names seem to be viewed as early history alternatives:
Cisco - Etherchannel
Juniper - Aggregated Ethernet
Others - Multi-link
BSD - lagg
Linux bonding
Solaris aggr
The point of this thread is to get consensus about best future naming.