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.
int
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.
Thanks.
-Hyong
