* [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
@ 2020-06-15 22:52 Stephen Hemminger
2020-06-16 10:03 ` Chas Williams
2020-06-16 11:48 ` Jay Rolette
0 siblings, 2 replies; 6+ messages in thread
From: Stephen Hemminger @ 2020-06-15 22:52 UTC (permalink / raw)
To: Chas Williams, Wei Hu (Xavier); +Cc: dev
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
2020-06-15 22:52 [dpdk-dev] Aligning DPDK Link bonding with current standards terminology Stephen Hemminger
@ 2020-06-16 10:03 ` Chas Williams
2020-06-16 11:48 ` Jay Rolette
1 sibling, 0 replies; 6+ messages in thread
From: Chas Williams @ 2020-06-16 10:03 UTC (permalink / raw)
To: Stephen Hemminger, Chas Williams, Wei Hu (Xavier); +Cc: dev
On 6/15/20 6:52 PM, Stephen Hemminger wrote:
> 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.
>
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
2020-06-15 22:52 [dpdk-dev] Aligning DPDK Link bonding with current standards terminology Stephen Hemminger
2020-06-16 10:03 ` Chas Williams
@ 2020-06-16 11:48 ` Jay Rolette
2020-06-16 13:52 ` Chas Williams
1 sibling, 1 reply; 6+ messages in thread
From: Jay Rolette @ 2020-06-16 11:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Chas Williams, Wei Hu (Xavier), DPDK
On Mon, Jun 15, 2020 at 5:52 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> 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.
> 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?
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
2020-06-16 11:48 ` Jay Rolette
@ 2020-06-16 13:52 ` Chas Williams
2020-06-16 15:45 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Chas Williams @ 2020-06-16 13:52 UTC (permalink / raw)
To: dev
On 6/16/20 7:48 AM, Jay Rolette wrote:
> On Mon, Jun 15, 2020 at 5:52 PM Stephen Hemminger <
> stephen@networkplumber.org> wrote:
>
>> 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.
>
>
>> 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.
>
>
>> 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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
2020-06-16 13:52 ` Chas Williams
@ 2020-06-16 15:45 ` Stephen Hemminger
2020-06-16 20:27 ` Chas Williams
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2020-06-16 15:45 UTC (permalink / raw)
To: Chas Williams; +Cc: dev
On Tue, 16 Jun 2020 09:52:01 -0400
Chas Williams <3chas3@gmail.com> wrote:
> On 6/16/20 7:48 AM, Jay Rolette wrote:
> > On Mon, Jun 15, 2020 at 5:52 PM Stephen Hemminger <
> > stephen@networkplumber.org> wrote:
> >
> >> 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.
> >
> >
> >> 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.
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
2020-06-16 15:45 ` Stephen Hemminger
@ 2020-06-16 20:27 ` Chas Williams
0 siblings, 0 replies; 6+ messages in thread
From: Chas Williams @ 2020-06-16 20:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On 6/16/20 11:45 AM, Stephen Hemminger wrote:
> On Tue, 16 Jun 2020 09:52:01 -0400
> Chas Williams <3chas3@gmail.com> wrote:
>
>> On 6/16/20 7:48 AM, Jay Rolette wrote:
>> > On Mon, Jun 15, 2020 at 5:52 PM Stephen Hemminger <
>> > stephen@networkplumber.org> wrote:
>> >
>> >> 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.
>> >
>> >
>> >> 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.
>
> 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.
> 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;
%
> 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.
> 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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-16 20:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-15 22:52 [dpdk-dev] Aligning DPDK Link bonding with current standards terminology Stephen Hemminger
2020-06-16 10:03 ` Chas Williams
2020-06-16 11:48 ` Jay Rolette
2020-06-16 13:52 ` Chas Williams
2020-06-16 15:45 ` Stephen Hemminger
2020-06-16 20:27 ` Chas Williams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).