[dpdk-dev] [PATCH v3 1/2] net/i40e: new API to add VF MAC address from PF

[Lu, Wenzhuo]

Hi,

> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Friday, August 18, 2017 12:43 PM
> To: Stephen Hemminger <stephen at networkplumber.org>; Lu, Wenzhuo
> <wenzhuo.lu at intel.com>
> Cc: dev at 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.lu at 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.lu at 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.