From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 4DA9D7D7B for ; Fri, 18 Aug 2017 18:43:14 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 18 Aug 2017 09:43:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,393,1498546800"; d="scan'208";a="301858738" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by fmsmga004.fm.intel.com with ESMTP; 18 Aug 2017 09:43:10 -0700 To: Stephen Hemminger , Wenzhuo Lu Cc: dev@dpdk.org References: <1500929487-72896-1-git-send-email-wenzhuo.lu@intel.com> <1502994823-125017-1-git-send-email-wenzhuo.lu@intel.com> <1502994823-125017-2-git-send-email-wenzhuo.lu@intel.com> <20170817173227.29bae83d@xeon-e3> From: Ferruh Yigit Message-ID: Date: Fri, 18 Aug 2017 17:43:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170817173227.29bae83d@xeon-e3> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3 1/2] net/i40e: new API to add VF MAC address from PF 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: Fri, 18 Aug 2017 16:43:15 -0000 On 8/18/2017 1:32 AM, Stephen Hemminger wrote: > On Fri, 18 Aug 2017 02:33:42 +0800 > Wenzhuo Lu wrote: > >> Currently, rte_eth_dev_mac_addr_add is used by a >> testpmd CLI to add a MAC address for VF. But the >> parameter 'pool' of this API means the VMDq pool, >> not VF. >> So, it's wrong to use it to add the VF MAC address. >> This patch provides a new API that can be used to >> add VF MAC address on i40e. >> >> Signed-off-by: Wenzhuo Lu > > What do other drivers do? This is adding VF MAC through PF, not all PMDs support this. > Sorry, a driver specific API is (almost) always the wrong solution. Currently there are set of device specific APIs [1]. The motivation was to be able to expose NIC specific features, abstraction layer should not prevent using HW features; while keeping abstraction clean for common majority, not having APIs valid only for a single NIC. But with number of the device specific APIs increasing, it may be time to bring postponed discussion to life on how to manage them. Recent ioclt or staging dev_ops was a good tart: http://dpdk.org/ml/archives/dev/2017-August/thread.html#72423 [1] Physical PMDs with device specific API: i40e, ixgbe, bnxt Virtual PMDs with device specific API: ring, vhost, bonding, xenvirt