Re: [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.

quoted

-----Original Message-----
From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
Sent: Friday, September 09, 2016 10:11 AM
To: Bernard Iremonger <redacted>
Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org;
ZELEZNIAK, ALEX [off-list ref]
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:

quoted

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 <redacted>
Signed-off-by: Bernard Iremonger <redacted>
---
 lib/librte_ether/rte_ethdev.c          | 17 ++++++++++
 lib/librte_ether/rte_ethdev.h          | 61

++++++++++++++++++++++++++++++++++

quoted

 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,

quoted

 			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)

*/

quoted

 	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

*/

quoted

+	RTE_ETH_MB_EVENT_NOOP_NACK, /**< skip mbox request and

NACK */

quoted

+	RTE_ETH_MB_EVENT_PROCEED,  /**< proceed with mbox request

*/

quoted

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