From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay-out5.mail.masterhost.ru (relay-out5.mail.masterhost.ru [83.222.12.15]) by dpdk.org (Postfix) with ESMTP id 211132BF3 for ; Tue, 19 Jun 2018 10:39:33 +0200 (CEST) Received: from [37.139.80.50] (helo=nw) by relay5.mail.masterhost.ru with esmtpa envelope from authenticated with alex@therouter.net message id 1fVCAj-0008Pp-EC; Tue, 19 Jun 2018 11:39:29 +0300 Date: Tue, 19 Jun 2018 11:39:23 +0300 From: Alex Kiselev Message-ID: <324558105.20180619113923@therouter.net> To: Matan Azrad , Chas Williams <3chas3@gmail.com>, Stephen Hemminger CC: Chas Williams , "dev@dpdk.org" In-Reply-To: References: <20180618122720.5B3F51559@dpdk.org> <20180618115833.161b14d8@xeon-e3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 125998 [Jun 19 2018] X-KLMS-AntiSpam-Version: 5.8.1.0 X-KLMS-AntiSpam-Envelope-From: alex@therouter.net X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Info: LuaCore: 145 145 8115312454756d54ead40e39a46e0295eb9efe85, {rep_avail}, DmarcAF: none X-MS-Exchange-Organization-SCL: -1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: not scanned, disabled by settings X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.2.16, not scanned, license restriction Subject: Re: [dpdk-dev] [PATCH v2] net/bonding: add add/remove mac addrs 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: , X-List-Received-Date: Tue, 19 Jun 2018 08:39:33 -0000 > From: Chas Williams >> On Mon, Jun 18, 2018 at 2:58 PM Stephen Hemminger < >> stephen@networkplumber.org> wrote: >> > On Mon, 18 Jun 2018 15:27:16 +0300 >> > Alex Kiselev wrote: >> > >> > > +static const struct ether_addr null_mac_addr; >> > > + >> > > +/* >> > > + * Add additional MAC addresses to the slave */ int >> > > +slave_add_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_add(slave_port_id, mac_addr, 0); >> > > + if (ret < 0) >> > > + return ret; >> > > + } >> > > + >> > > + return 0; >> > You need to unwind if adding MAC address to one of the slave devices >> > worked, and the second one did not. >> > Done in patch v3. Also, I've added the same rollback to bond_ethdev_mac_addr_add(). > Agree. >> Yes, probably. But that doesn't help with the new slave problem. If you add a >> new slave and it is unable to add all the MAC addresses, what then? The only >> reasonable thing might be to put that interface into promiscuous mode. > I think that in this case the slave should be rejected. > The reason is that all the slaves should be able to receive\send the same traffic all the time. >> At some point you need to draw the line, where is the PMD and where is the >> application? >> Thankfully, people tend to enslave the same types of PMDs and the capabilities >> are generally similar. > So, I think we need to enforce it in the bonding PMD. > Please look at the bonding rte_flow design \ RSS conf (also in bonding documentation): > The main principle in the design is that all the time all the > slaves able to get\send the same traffic: > So, a new slave which cannot apply all the current bonding flow rules will be rejected. > And a new rule which cannot be applied to all the current slaves > will be rejected and deleted from all the slaves. > I think it should be the same for mac address adding and all the > other configurations which affect a traffic receiving\sending. -- Alex