[dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions

[Jerin Jacob]

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.
> > >