[dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF management
Iremonger, Bernard
bernard.iremonger at intel.com
Mon Sep 12 18:28:06 CEST 2016
Hi Jerin,
<snip>
> Subject: Re: [dpdk-dev] [RFC PATCH v2 3/5] librte_ether: add API's for VF
> management
>
> 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 at 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.
>
> 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_rate, uint64_t q_msk)
>
> > increment LIBABIVER to 5.
> >
> > Signed-off-by: Bernard Iremonger <bernard.iremonger at 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 = &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 = &rte_eth_devices[port_id];
> > + if (vf > 63) {
>
> PMD may have more than 64 VFs.
Yes, it would be better to check on max_vfs, the same way as the already implemented functions mentioned above.
>
>
> > + 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.
More information about the dev
mailing list