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

[Iremonger, Bernard]

Hi Jerin, Thomas,

<snip>

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

The AT&T requirement is to have the application controlling the PF (for example VFD) receive information via a callback when a VF mailbox event is received (for example IXGBE_VF_SET_VLAN) to decide whether to allow or deny a VF request. 

Do you have any suggestions on how the above requirement can be met without "exposing the fine details of PF/VF MBOX scheme in the ethdev spec".

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