Re: [dpdk-stable] [dpdk-dev] [PATCH] ethdev: fix setting of MAC address

[Olivier Matz <olivier.matz@6wind.com>]

On Mon, Jan 08, 2018 at 11:59:09AM +0000, Ferruh Yigit wrote:
> On 1/3/2018 2:12 PM, Andrew Rybchenko wrote:
> > On 01/03/2018 04:54 PM, Olivier Matz wrote:
> >> On Wed, Jan 03, 2018 at 02:43:59PM +0100, Olivier Matz wrote:
> >>> I've walked through the PMDs as suggested by Andrew, and there was
> >>> indeed some conflicts with the initial patch. I've just submitted the
> >>> patch for vmxnet3 [1] and bnxt [2].
> >>>
> >>> But there is still an issue with the qede driver, that overwrites the
> >>> MAC address in dev->data by the previous one if it cannot be set. It
> >>> seems it's the only driver that does this in error case, but anyway,
> >>> this behavior will be broken by the initial patch.
> >>>
> >>> So I submitted a v2 that only changes the behavior for i40evf [3].
> >>>
> >>> I propose to include these 3 patches for 18.02, and announce an ABI
> >>> change for 18.05 to add a return value to dev_ops->mac_addr_set() and
> >>> move the ether_addr_copy() after the callback, only in case of success.
> >>>
> >>> Any opinions?
> > 
> > I'm not sure if dev_ops->mac_addr_set() is a part of ABI.
> > It is an internal interface between rte_ethdev library and drivers. Yes, out-of-tree
> > drivers will be broken.
> > rte_eth_dev_default_mac_addr_set() is definitely a part of API/ABI, but it already
> > has return value.
> > So, I'm not sure that we have to wait for 18.05, but it is still may be too late for
> > 18.02 since integration deadline is pretty close.
> 
> I think there is no API/ABI breakage, but it can be good to announce the change
> and give time for modifications.
> 
> +1 for proposal.

Thanks Andrew and Ferruh for the feedback.
I'll send an RFC for this soon.