Hi, > -----Original Message----- > From: Yigit, Ferruh > Sent: Friday, August 18, 2017 12:43 PM > To: Stephen Hemminger <step...@networkplumber.org>; Lu, Wenzhuo > <wenzhuo...@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/2] net/i40e: new API to add VF MAC > address from PF > > On 8/18/2017 1:32 AM, Stephen Hemminger wrote: > > On Fri, 18 Aug 2017 02:33:42 +0800 > > Wenzhuo Lu <wenzhuo...@intel.com> 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 <wenzhuo...@intel.com> > > > > 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 This patch follows the existing bnxt example to implement the same function on i40e.
Totally agree the private API is not a good idea. To my opinion, as many same functions are implemented on ixgbe, i40e, bnxt, it's them time to make them public. Let me send some RFC later.
