On Mon, Feb 19, 2018 at 01:42:27PM +0100, David Marchand wrote:
> Reused the .mac_addr_add and .mac_addr_del callbacks code to implement
> primary mac address handler.
> Signed-off-by: David Marchand <david.march...@6wind.com>

Hi, thanks for taking a stab at this.

> +static void enicpmd_set_mac_addr(struct rte_eth_dev *eth_dev,
> +     struct ether_addr *addr)
> +{
> +     enicpmd_remove_mac_addr(eth_dev, 0);
> +     enicpmd_add_mac_addr(eth_dev, addr, 0, 0);
> +}

Unfortunately, this does not work as expected. The caller updates
mac_addrs[0] prior to calling mac_addr_set.

rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct ether_addr *addr)
        /* Update default address in NIC data structure */
        ether_addr_copy(addr, &dev->data->mac_addrs[0]);

        (*dev->dev_ops->mac_addr_set)(dev, addr);

So, enicpmd_remove_mac_addr tries to remove mac_addrs[0], which is the
'new' default address and does not exist on the NIC. Then,
enicpmd_add_mac_addr adds the new address to the NIC. At the end, the
NIC ends up with both the old and the new addresses.

I think the driver would have to treat the 'default' mac address
differently. I can submit a new patch as part of our next upstream
patch set. Or you are welcome to spin a new version. Up to you.


Reply via email to