Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Wednesday, September 14, 2016 12:28 PM > To: ZELEZNIAK, ALEX <az5157 at att.com> > Cc: Iremonger, Bernard <bernard.iremonger at intel.com>; Shah, Rahul R > <rahul.r.shah at intel.com>; Lu, Wenzhuo <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 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.
I have reworked these patches (1/5 and 2/5) using the new rte_pmd_ixgbe.h file and submitted as a separate patchset. [PATCH v3 0/2] add callbacks for VF management http://dpdk.org/dev/patchwork/patch/16321/ http://dpdk.org/dev/patchwork/patch/16322/ Regards, Bernard. > > > -----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. > > > >
