From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bernard.iremonger@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id BA299567F
 for <dev@dpdk.org>; Mon, 12 Sep 2016 18:28:10 +0200 (CEST)
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by fmsmga103.fm.intel.com with ESMTP; 12 Sep 2016 09:28:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.30,323,1470726000"; 
   d="scan'208";a="7604956"
Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66])
 by orsmga005.jf.intel.com with ESMTP; 12 Sep 2016 09:28:08 -0700
Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by
 IRSMSX152.ger.corp.intel.com (163.33.192.66) with Microsoft SMTP Server (TLS)
 id 14.3.248.2; Mon, 12 Sep 2016 17:28:07 +0100
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.71]) by
 irsmsx155.ger.corp.intel.com ([169.254.14.102]) with mapi id 14.03.0248.002;
 Mon, 12 Sep 2016 17:28:07 +0100
From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
CC: "Shah, Rahul R" <rahul.r.shah@intel.com>, "Lu, Wenzhuo"
 <wenzhuo.lu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, azelezniak
 <alexz@att.com>
Thread-Topic: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF
 management
Thread-Index: AQHR/3nL92Tihh00JUigC2GSiYccqaBxO5UAgATmckA=
Date: Mon, 12 Sep 2016 16:28:06 +0000
Message-ID: <8CEF83825BEC744B83065625E567D7C21A0761A7@IRSMSX108.ger.corp.intel.com>
References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com>
 <1472202620-20487-1-git-send-email-bernard.iremonger@intel.com>
 <1472202620-20487-4-git-send-email-bernard.iremonger@intel.com>
 <20160909142251.GB4100@localhost.localdomain>
In-Reply-To: <20160909142251.GB4100@localhost.localdomain>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGY3NmJmMTAtNGU3My00NTdkLTg2NWQtNjE1ZmVmYmJiNjMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Img0TnM4VmtUZ3p6TEkzWGswREhzSWVyZ2hwMWExQ1d5MVpoRGwwVTVBXC9nPSJ9
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF
 management
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2016 16:28:11 -0000

Hi Jerin,

<snip>

> Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF
> management
>=20
> On Fri, Aug 26, 2016 at 10:10:18AM +0100, Bernard Iremonger wrote:
> > Add new API functions to configure and manage VF's on a NIC.
> >
> > add rte_eth_dev_vf_ping function.
> > add rte_eth_dev_set_vf_vlan_anti_spoof function.
> > add rte_eth_dev_set_vf_mac_anti_spoof function.
> >
> > Signed-off-by: azelezniak <alexz@att.com>
> >
> > add rte_eth_dev_set_vf_vlan_strip function.
> > add rte_eth_dev_set_vf_vlan_insert function.
> > add rte_eth_dev_set_loopback function.
> > add rte_eth_dev_set_all_queues_drop function.
> > add rte_eth_dev_set_vf_split_drop_en function add
> > rte_eth_dev_set_vf_mac_addr function.
>=20
> Do we really need to expose VF specific functions here?
> It can be generic(PF/VF) function indexed only through port_id.
> (example: as rte_eth_dev_set_vlan_anti_spoof(uint8_t port_id, uint8_t on)=
)
> For instance, In Thunderx PMD, We are not exposing a separate port_id for
> PF. We only enumerate 0..N VFs as 0..N ethdev port_id

Our intention with this patch is to control the VF from the PF.

The following librte_ether functions already work in a similar way:

rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf, uint16_t rx_mode, =
uint8_t on)

rte_eth_dev_set_vf_rx(uint8_t port_id, uint16_t vf, uint8_t on)

rte_eth_dev_set_vf_tx(uint8_t port_id, uint16_t vf, uint8_t on)

int rte_eth_set_vf_rate_limit(uint8_t port_id, uint16_t vf, uint16_t tx_rat=
e, uint64_t q_msk)

>=20
> > increment LIBABIVER to 5.
> >
> > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > ---
> >  lib/librte_ether/rte_ethdev.c          | 159 +++++++++++++++++++++++
> >  lib/librte_ether/rte_ethdev.h          | 223
> +++++++++++++++++++++++++++++++++
> >  lib/librte_ether/rte_ether_version.map |   9 ++
> >  3 files changed, 391 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c
> > b/lib/librte_ether/rte_ethdev.c index 1388ea3..2a3d2ae 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -2306,6 +2306,22 @@ rte_eth_dev_default_mac_addr_set(uint8_t
> > port_id, struct ether_addr *addr)  }
> >
> >  int
> > +rte_eth_dev_set_vf_mac_addr(uint8_t port_id, uint16_t vf, struct
> > +ether_addr *addr) {
> > +	struct rte_eth_dev *dev;
> > +
> > +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > +	if (!is_valid_assigned_ether_addr(addr))
> > +		return -EINVAL;
> > +
> > +	dev =3D &rte_eth_devices[port_id];
> > +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_vf_mac_addr, -
> ENOTSUP);
> > +
> > +	return (*dev->dev_ops->set_vf_mac_addr)(dev, vf, addr); }
> > +
> > +int
> >  rte_eth_dev_set_vf_rxmode(uint8_t port_id,  uint16_t vf,
> >  				uint16_t rx_mode, uint8_t on)
> >  {
> > @@ -2490,6 +2506,149 @@ rte_eth_dev_set_vf_vlan_filter(uint8_t
> port_id, uint16_t vlan_id,
> >  						   vf_mask, vlan_on);
> >  }
> >
> > +int
> > +rte_eth_dev_set_vf_vlan_anti_spoof(uint8_t port_id,
> > +			       uint16_t vf, uint8_t on)
> > +{
> > +	struct rte_eth_dev *dev;
> > +
> > +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > +	dev =3D &rte_eth_devices[port_id];
> > +	if (vf > 63) {
>=20
> PMD may have more than 64 VFs.

Yes, it would be better to check on max_vfs,  the same way as the already i=
mplemented functions mentioned above.
=20
>=20
>=20
> > +		RTE_PMD_DEBUG_TRACE("VF VLAN anti spoof:VF %d >
> 63\n", vf);
> > +		return -EINVAL;
> > +	}
> > +
> > +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops-
> >set_vf_vlan_anti_spoof, -ENOTSUP);
> > +	(*dev->dev_ops->set_vf_vlan_anti_spoof)(dev, vf, on);
> > +	return 0;
> > +}
> > +

Thanks for reviewing.
Regards,

Bernard.