On Mon, Jun 18, 2018 at 2:58 PM Stephen Hemminger <
step...@networkplumber.org> wrote:
> On Mon, 18 Jun 2018 15:27:16 +0300
> Alex Kiselev <a...@therouter.net> 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.
>
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. 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.
