From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 76A1E282 for ; Sun, 7 May 2017 06:43:05 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2017 21:43:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,302,1491289200"; d="scan'208";a="84517945" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga004.jf.intel.com with ESMTP; 06 May 2017 21:43:00 -0700 Date: Sun, 7 May 2017 12:39:10 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: Wei Dai , dev@dpdk.org, wenzhuo.lu@intel.com, harish.patil@cavium.com, rasesh.mody@cavium.com, stephen.hurd@broadcom.com, ajit.khaparde@broadcom.com, helin.zhang@intel.com, konstantin.ananyev@intel.com, jingjing.wu@intel.com, jing.d.chen@intel.com, adrien.mazarguil@6wind.com, nelio.laranjeiro@6wind.com, bruce.richardson@intel.com, maxime.coquelin@redhat.com, shepard.siegel@atomicrules.com, ed.czeck@atomicrules.com, john.miller@atomicrules.com Message-ID: <20170507043910.GF3005@yliu-dev.sh.intel.com> References: <1493729065-17090-1-git-send-email-wei.dai@intel.com> <1493944802-52943-1-git-send-email-wei.dai@intel.com> <1493944802-52943-2-git-send-email-wei.dai@intel.com> <7497469.TuTdfvjb2m@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7497469.TuTdfvjb2m@xps> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v7 1/3] ethdev: fix adding invalid MAC addr 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: Sun, 07 May 2017 04:43:05 -0000 On Fri, May 05, 2017 at 04:21:53PM +0200, Thomas Monjalon wrote: > 05/05/2017 02:40, Wei Dai: > > Some customers find adding MAC addr to VF sometimes can fail, > > but it is still stored in dev->data->mac_addrs[ ]. So this > > can lead to some errors that assumes the non-zero entry in > > dev->data->mac_addrs[ ] is valid. > > Following acknowledgements are from specific NIC PMD > > maintainer for their managing part. > > > > This patch changes the ethdev API, it should not be > > backported to a stable/LTS release so far. > > It changes only the internal function pointer used by drivers, > not the API. Oh, right. I was thinking the eth API rte_eth_dev_mac_addr also has to be changed. It turned out that it's already been designed with returning "int". Sorry for the noise. --yliu