[dpdk-dev] Aligning DPDK Link bonding with current standards terminology
Stephen Hemminger
stephen at networkplumber.org
Tue Jun 16 17:45:09 CEST 2020
On Tue, 16 Jun 2020 09:52:01 -0400
Chas Williams <3chas3 at 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 at 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.
More information about the dev
mailing list