On Tue, Sep 13, 2016 at 02:05:49PM +0000, ZELEZNIAK, ALEX wrote: > Idea here is not to allow VM to control policies assigned to it for security > and other reasons. PF is controlled by host and dictates what VM can and > can't do in regards of setting VF parameters.
I think the proposed scheme, The VM does not take any action on its own. The VM will just follow what the centralized entity to do so. I think if you are planning to support different varieties of PMD then this could be an option.However, if you wish to support only a subset of PMDs then PF MBOX based scheme may be enough. In any case, I think exposing the fine details of PF/VF MBOX scheme in the ethdev spec is not a good idea. > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > > Sent: Tuesday, September 13, 2016 4:46 AM > > To: ZELEZNIAK, ALEX <az5157 at att.com> > > Cc: Bernard Iremonger <bernard.iremonger at intel.com>; > > rahul.r.shah at intel.com; wenzhuo.lu at intel.com; dev at dpdk.org > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > callback functions > > > > On Fri, Sep 09, 2016 at 04:32:07PM +0000, ZELEZNIAK, ALEX wrote: > > > Use case could be to inform application managing SRIOV about VM's > > intention > > > to modify parameters like add VLAN which might not be the one which is > > > assigned to VF or inform about VF reset and reapply settings like > > strip/insert > > > VLAN id based on policy. > > > > Is there any other way(more portable way) where we can realize the same > > use case? > > > > Something like, > > > > 1) The assigned VM operates/control the VF > > 2) A centralized entity post messages through UNIX socket or > > something(like vhost user communicates with VM). > > On message receive, VM can take necessary action on assigned VF. > > > > This will avoid the need of defining specifics of PF to VF mailbox > > communication in normative ethdev specification. > > > > And I guess it will work almost the PMD drivers as their is no > > PMD specific work here. > > > > Just a thought. > > > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > > > > Sent: Friday, September 09, 2016 10:11 AM > > > > To: Bernard Iremonger <bernard.iremonger at intel.com> > > > > Cc: rahul.r.shah at intel.com; wenzhuo.lu at intel.com; dev at dpdk.org; > > > > ZELEZNIAK, ALEX <az5157 at att.com> > > > > Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal > > > > callback functions > > > > > > > > On Fri, Aug 26, 2016 at 10:10:16AM +0100, Bernard Iremonger wrote: > > > > > add _rte_eth_dev_callback_process_vf function. > > > > > add _rte_eth_dev_callback_process_generic function > > > > > > > > > > Adding a callback to the user application on VF to PF mailbox message, > > > > > allows passing information to the application controlling the PF > > > > > when a VF mailbox event message is received, such as VF reset. > > > > > > > > > > Signed-off-by: azelezniak <alexz at att.com> > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger at intel.com> > > > > > --- > > > > > lib/librte_ether/rte_ethdev.c | 17 ++++++++++ > > > > > lib/librte_ether/rte_ethdev.h | 61 > > > > ++++++++++++++++++++++++++++++++++ > > > > > lib/librte_ether/rte_ether_version.map | 7 ++++ > > > > > 3 files changed, 85 insertions(+) > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > b/lib/librte_ether/rte_ethdev.c > > > > > index f62a9ec..1388ea3 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.c > > > > > +++ b/lib/librte_ether/rte_ethdev.c > > > > > @@ -2690,6 +2690,20 @@ void > > > > > _rte_eth_dev_callback_process(struct rte_eth_dev *dev, > > > > > enum rte_eth_event_type event) > > > > > { > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, NULL); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_vf(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > + return _rte_eth_dev_callback_process_generic(dev, event, param); > > > > > +} > > > > > + > > > > > +void > > > > > +_rte_eth_dev_callback_process_generic(struct rte_eth_dev *dev, > > > > > + enum rte_eth_event_type event, void *param) > > > > > +{ > > > > > struct rte_eth_dev_callback *cb_lst; > > > > > struct rte_eth_dev_callback dev_cb; > > > > > > > > > > @@ -2699,6 +2713,9 @@ _rte_eth_dev_callback_process(struct > > > > rte_eth_dev *dev, > > > > > continue; > > > > > dev_cb = *cb_lst; > > > > > cb_lst->active = 1; > > > > > + if (param != NULL) > > > > > + dev_cb.cb_arg = (void *) param; > > > > > + > > > > > rte_spinlock_unlock(&rte_eth_dev_cb_lock); > > > > > dev_cb.cb_fn(dev->data->port_id, dev_cb.event, > > > > > dev_cb.cb_arg); > > > > > diff --git a/lib/librte_ether/rte_ethdev.h > > b/lib/librte_ether/rte_ethdev.h > > > > > index b0fe033..4fb0b9c 100644 > > > > > --- a/lib/librte_ether/rte_ethdev.h > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > @@ -3047,9 +3047,27 @@ enum rte_eth_event_type { > > > > > /**< queue state event > > > > > (enabled/disabled) > > > > */ > > > > > RTE_ETH_EVENT_INTR_RESET, > > > > > /**< reset interrupt event, sent to VF on PF > > > > > reset */ > > > > > + RTE_ETH_EVENT_VF_MBOX, /**< PF mailbox processing callback */ > > > > > RTE_ETH_EVENT_MAX /**< max value of this enum */ > > > > > }; > > > > > > > > > > +/** > > > > > + * Response sent back to ixgbe driver from user app after callback > > > > > + */ > > > > > +enum rte_eth_mb_event_rsp { > > > > > + RTE_ETH_MB_EVENT_NOOP_ACK, /**< skip mbox request and ACK > > > > */ > > > > > + RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and > > > > NACK */ > > > > > + RTE_ETH_MB_EVENT_PROCEED, /**< proceed with mbox request > > > > */ > > > > > + RTE_ETH_MB_EVENT_MAX /**< max value of this enum */ > > > > > +}; > > > > > > > > Do we really need to define the specifics of PF to VF MBOX > > communication > > > > in normative ethdev specification? > > > > Each drivers may have different PF to VF MBOX definitions so it may not > > be > > > > very portable. > > > > What is the use-case here? If its for VF configuration, I think we can > > > > do it as separate 'sync' functions for each functionality so that > > > > PMDs will have room hiding the specifics on MBOX definitions. > > >
