From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 9C1093250; Mon, 8 Jan 2018 15:23:49 +0100 (CET) Received: from lfbn-lil-1-110-231.w90-45.abo.wanadoo.fr ([90.45.197.231] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eYYKv-0002zf-3e; Mon, 08 Jan 2018 15:23:38 +0100 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 08 Jan 2018 15:23:35 +0100 Date: Mon, 8 Jan 2018 15:23:35 +0100 From: Olivier Matz To: Ferruh Yigit Cc: Andrew Rybchenko , Ivan Malov , Igor Ryzhov , dev@dpdk.org, Thomas Monjalon , Laurent Hardy , stable@dpdk.org Message-ID: <20180108142334.2s4h66sce57f3ss3@platinum> References: <20171219092932.5k5sg3eemfghatkl@glumotte.dev.6wind.com> <20180103134358.rc4funbiws5mlimh@platinum> <20180103135409.jwltlb45hfhnqwoh@platinum> <91395f4d-9f40-943b-245a-1858aec91588@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH] ethdev: fix setting of MAC address X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 14:23:49 -0000 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.