From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [PATCH] ethdev: fix setting of MAC address
Date: Mon, 18 Dec 2017 14:38:55 +0300
Message-ID: <acca024b-f96d-9d37-9f38-f63e5f7317f2@solarflare.com>
References: <20171214171531.10506-1-olivier.matz@6wind.com>
 <adea1787-9c1c-3942-3b9e-ea42a2e44728@solarflare.com>
 <CAF+s_FyBQfevMSaLHH9xOV=+DvTwk70XNcOrtGToumhKvs-kMA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Olivier Matz <olivier.matz@6wind.com>, <dev@dpdk.org>, Thomas Monjalon
 <thomas@monjalon.net>, Laurent Hardy <laurent.hardy@6wind.com>,
 <stable@dpdk.org>
To: Igor Ryzhov <iryzhov@nfware.com>
Return-path: <dev-bounces@dpdk.org>
In-Reply-To: <CAF+s_FyBQfevMSaLHH9xOV=+DvTwk70XNcOrtGToumhKvs-kMA@mail.gmail.com>
Content-Language: en-GB
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
>
> On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko 
> <arybchenko@solarflare.com <mailto:arybchenko@solarflare.com>> wrote:
>
>     On 12/14/2017 08:15 PM, Olivier Matz wrote:
>
>         From: Laurent Hardy <laurent.hardy@6wind.com
>         <mailto:laurent.hardy@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: stable@dpdk.org <mailto:stable@dpdk.org>
>
>         Signed-off-by: Laurent Hardy <laurent.hardy@6wind.com
>         <mailto:laurent.hardy@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.