From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex Kiselev <alex@therouter.net>
Subject: Re: [PATCH v2] net/bonding: add add/remove mac addrs
Date: Tue, 19 Jun 2018 11:41:05 +0300
Message-ID: <1235275709.20180619114105@therouter.net>
References: <20180618122720.5B3F51559@dpdk.org>
 <20180618120019.66b3bfbb@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: Chas Williams <chas3@att.com>, "dev@dpdk.org" <dev@dpdk.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from relay-out5.mail.masterhost.ru (relay-out5.mail.masterhost.ru
 [83.222.12.15]) by dpdk.org (Postfix) with ESMTP id BA5CF1C0B
 for <dev@dpdk.org>; Tue, 19 Jun 2018 10:41:12 +0200 (CEST)
In-Reply-To: <20180618120019.66b3bfbb@xeon-e3>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



> On Mon, 18 Jun 2018 15:27:16 +0300
> Alex Kiselev <alex@therouter.net> wrote:

>> +/*
>> + * Remove additional MAC addresses from the slave
>> + */
>> +int
>> +slave_remove_mac_addresses(struct rte_eth_dev *bonded_eth_dev,
>> +             uint16_t slave_port_id)
>> +{
>> +     int i, ret;
>> +     struct ether_addr *mac_addr;
>> +
>> +     /* add additional MACs to the slave */
>> +     for (i = 1; i < BOND_MAX_MAC_ADDRS; i++) {
>> +             mac_addr = &bonded_eth_dev->data->mac_addrs[i];
>> +             if (is_same_ether_addr(mac_addr, &null_mac_addr))
>> +                     break;
>> +
>> +             ret = rte_eth_dev_mac_addr_remove(slave_port_id, mac_addr);
>> +             if (ret < 0)
>> +                     return ret;
>> +     }

> Not sure this is the best semantic if remove fails on one of many
> slaves. Perhaps it should always remove it from all slaves.

> Or maybe a first pass to see if the address exists, then
> a no-fail removal pass.

I think to always remove is the right thing.
Done in the patch v3

-- 
Alex