From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 3AADF1B01E; Mon, 8 Jan 2018 12:59:13 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 03:59:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,330,1511856000"; d="scan'208";a="191344720" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.48]) ([10.237.220.48]) by orsmga005.jf.intel.com with ESMTP; 08 Jan 2018 03:59:10 -0800 To: Andrew Rybchenko , Olivier Matz Cc: Ivan Malov , Igor Ryzhov , dev@dpdk.org, Thomas Monjalon , Laurent Hardy , stable@dpdk.org References: <20171214171531.10506-1-olivier.matz@6wind.com> <20171219092932.5k5sg3eemfghatkl@glumotte.dev.6wind.com> <20180103134358.rc4funbiws5mlimh@platinum> <20180103135409.jwltlb45hfhnqwoh@platinum> <91395f4d-9f40-943b-245a-1858aec91588@solarflare.com> From: Ferruh Yigit Message-ID: Date: Mon, 8 Jan 2018 11:59:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <91395f4d-9f40-943b-245a-1858aec91588@solarflare.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 11:59:14 -0000 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. > >> [1] https://dpdk.org/dev/patchwork/patch/32855/ >> [2] https://dpdk.org/dev/patchwork/patch/32856/ >> [3] https://dpdk.org/dev/patchwork/patch/32857/ > > Many thanks for drivers review and fixes.