On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko
<arybche...@solarflare.com <mailto:arybche...@solarflare.com>> wrote:
On 12/14/2017 08:15 PM, Olivier Matz wrote:
From: Laurent Hardy <laurent.ha...@6wind.com
<mailto:laurent.ha...@6wind.com>>
When a new mac address is set, it is saved in dev->data->mac_addrs
before the ethdev handler is called.
First, it is inconsistent with the other ethdev functions
rte_eth_dev_mac_addr_remove() and rte_eth_dev_mac_addr_add().
Moreover, it prevents the drivers from wrongly comparing the
old address
and the new one, like it's done in i40evf driver:
if (is_same_ether_addr(mac_addr, dev->data->mac_addrs))
return;
Fixes: 943c2d899a0c ("net/i40e: set VF MAC from VF")
Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: sta...@dpdk.org <mailto:sta...@dpdk.org>
Signed-off-by: Laurent Hardy <laurent.ha...@6wind.com
<mailto:laurent.ha...@6wind.com>>
---
lib/librte_ether/rte_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c
b/lib/librte_ether/rte_ethdev.c
index 4f492e3db..297c02a54 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2643,11 +2643,11 @@
rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct
ether_addr *addr)
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_set,
-ENOTSUP);
+ (*dev->dev_ops->mac_addr_set)(dev, 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);
-
return 0;
}
NACK, unfortunately it will break net/sfc in one of branches when
a new MAC
is set using restart. It relies on the fact that a new MAC is
already available in
device data.
> Hello Andrew,
>
> Don't you think that it's not correct that net/sfc works that way?
>
> If we go further, dev->dev_ops->mac_addr_set not only should be
called before ether_addr_copy.
It should return status code, and in case of error ether_addr_copy shouldn't be
called at all.
Am I wrong?
Current behaviour is convenient. Alternative will require copy of MAC
address
to set in device private data and one more copy in the function to
rollback in
the case of failure. If there are good reasons to change behaviour, I don't
mind but PMDs should be reviewed carefully and fixed before the change.
