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

  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@att.com>
Signed-off-by: Bernard Iremonger <bernard.iremonger@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(+)
  

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@att.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@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.
  

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@caviumnetworks.com]
> > Sent: Friday, September 09, 2016 10:11 AM
> > To: Bernard Iremonger <bernard.iremonger@intel.com>
> > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org;
> > ZELEZNIAK, ALEX <az5157@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@att.com>
> > > Signed-off-by: Bernard Iremonger <bernard.iremonger@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.
>
  

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@caviumnetworks.com]
> > Sent: Tuesday, September 13, 2016 4:46 AM
> > To: ZELEZNIAK, ALEX <az5157@att.com>
> > Cc: Bernard Iremonger <bernard.iremonger@intel.com>;
> > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@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@caviumnetworks.com]
> > > > Sent: Friday, September 09, 2016 10:11 AM
> > > > To: Bernard Iremonger <bernard.iremonger@intel.com>
> > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org;
> > > > ZELEZNIAK, ALEX <az5157@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@att.com>
> > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@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.
> > >
  

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@caviumnetworks.com]
> > > Sent: Tuesday, September 13, 2016 4:46 AM
> > > To: ZELEZNIAK, ALEX <az5157@att.com>
> > > Cc: Bernard Iremonger <bernard.iremonger@intel.com>;
> > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@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@caviumnetworks.com]
> > > > > Sent: Friday, September 09, 2016 10:11 AM
> > > > > To: Bernard Iremonger <bernard.iremonger@intel.com>
> > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org;
> > > > > ZELEZNIAK, ALEX <az5157@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@att.com>
> > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@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.
> > > >
  

Hi Jerin,

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Wednesday, September 14, 2016 12:28 PM
> To: ZELEZNIAK, ALEX <az5157@att.com>
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>; Shah, Rahul R
> <rahul.r.shah@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> dev@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@caviumnetworks.com]
> > > Sent: Tuesday, September 13, 2016 4:46 AM
> > > To: ZELEZNIAK, ALEX <az5157@att.com>
> > > Cc: Bernard Iremonger <bernard.iremonger@intel.com>;
> > > rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@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@caviumnetworks.com]
> > > > > Sent: Friday, September 09, 2016 10:11 AM
> > > > > To: Bernard Iremonger <bernard.iremonger@intel.com>
> > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org;
> > > > > ZELEZNIAK, ALEX <az5157@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@att.com>
> > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@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.
> > > >