From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9A520A04A5; Tue, 16 Jun 2020 22:27:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6B7261BFAB; Tue, 16 Jun 2020 22:27:32 +0200 (CEST) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by dpdk.org (Postfix) with ESMTP id 866771BFAA for ; Tue, 16 Jun 2020 22:27:31 +0200 (CEST) Received: by mail-qv1-f47.google.com with SMTP id e2so10176738qvw.7 for ; Tue, 16 Jun 2020 13:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Ekcl/FylVTEQ1nz43JRgbcR4H+lIXFw+peLcea0D3uM=; b=dlRfQBrGPiRK9T95mmK3Ty9LmemR5H/szmb/IqvFSS/5A6RpFsFwttV4F8FbSc5ZZh hKUucMjv69hGZrQWJRMFfsAxqHGbqHRsDkDmj4cxE3tlhLvZeManJwLOmjqmII23sd1I Ozijjm2fucT/MOQxSIeZ3ogArxOmr4aiAku2sBvjfh5FVf9Qu7MB14GA7wL54yoFEReJ eKcXDV+k/I4SCGen8fwxcBw8C6ssC8DQr12sl99t0m5vhIoa4gDigBjUA7qZPaMxz8qQ Xwbm1UjQQbgzMoSl+ZnaP2Zp/qffi1Xj38QBGq+QvRwj12VpFTiDrQtK6BVXwmwIH4o5 GP+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ekcl/FylVTEQ1nz43JRgbcR4H+lIXFw+peLcea0D3uM=; b=GKTy8rbPsCDjttrqv3nl5fo3u3+2Z6U5gEsfs3pYFFjG2sS1oKC9BpnpocgIV15hOM I6apRYiiFChxc/DtsUJMzH3iII/kW5IuJndNn7Uq6/lYkWlpnn/iBpQRAWfMHTMfV9sF FWp2T0QByV8ew0PeIaTFCUkpHCS3D/bBJLczz8/89EeprWDMv87a2k4bl/q0XK3dP/P/ 60NlfUVt+2Af8xAk7NRqOXpsTywJqXxTEB1D7yc6GClj5bQgWPQVncaqjoCbpUJpCmDN biFIH5hjXCUFMCZ1YpNVCuRmuLnAVYP+jel4rC+PLxTNQNo/EzqfK5JfDNv9VuAO/56T emOQ== X-Gm-Message-State: AOAM532fibYapfSEoQ1Wnp5IhChgbfoKS2Ds370CJXVXbOFKHLtrgp0+ 3AnaAfhN+L5VtQZhXy2tUzEgZP7r X-Google-Smtp-Source: ABdhPJxP6ZH40RlfhuIVLcnUM6xIZ4+a81Kp0+sxxTOhBGQaEKHfNXCu+CdvEIZLBwe8QREhazZOuw== X-Received: by 2002:ad4:49aa:: with SMTP id u10mr4351327qvx.162.1592339250535; Tue, 16 Jun 2020 13:27:30 -0700 (PDT) Received: from [192.168.1.10] (pool-96-255-60-31.washdc.fios.verizon.net. [96.255.60.31]) by smtp.gmail.com with ESMTPSA id z9sm14858995qkj.129.2020.06.16.13.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 13:27:30 -0700 (PDT) To: Stephen Hemminger Cc: dev@dpdk.org References: <20200615155237.682a89af@hermes.lan> <20200616084509.2810b5d4@hermes.lan> From: Chas Williams <3chas3@gmail.com> Message-ID: Date: Tue, 16 Jun 2020 16:27:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200616084509.2810b5d4@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Aligning DPDK Link bonding with current standards terminology X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "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. >