From: Chas Williams <3chas3@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology
Date: Tue, 16 Jun 2020 16:27:29 -0400 [thread overview]
Message-ID: <cf8db709-d913-0ec5-92c6-4f32486dff16@gmail.com> (raw)
In-Reply-To: <20200616084509.2810b5d4@hermes.lan>
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.
>
prev parent reply other threads:[~2020-06-16 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 22:52 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 message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf8db709-d913-0ec5-92c6-4f32486dff16@gmail.com \
--to=3chas3@gmail.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).