From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [RFC PATCH v2 1/5] librte_ether: add internal callback functions Date: Wed, 14 Sep 2016 16:58:13 +0530 Message-ID: <20160914112811.GA8364@localhost.localdomain> References: <1471528125-26357-1-git-send-email-bernard.iremonger@intel.com> <1472202620-20487-1-git-send-email-bernard.iremonger@intel.com> <1472202620-20487-2-git-send-email-bernard.iremonger@intel.com> <20160909141031.GA4100@localhost.localdomain> <3C0218D8B3DD114D8DBFE6B68141FBE3185F9FE7@MISOUT7MSGUSRDI.ITServices.sbc.com> <20160913084535.GA6750@localhost.localdomain> <3C0218D8B3DD114D8DBFE6B68141FBE3185FDCDC@MISOUT7MSGUSRDI.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Bernard Iremonger , "rahul.r.shah@intel.com" , "wenzhuo.lu@intel.com" , "dev@dpdk.org" To: "ZELEZNIAK, ALEX" Return-path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0085.outbound.protection.outlook.com [104.47.34.85]) by dpdk.org (Postfix) with ESMTP id 0FD558DA1 for ; Wed, 14 Sep 2016 13:28:40 +0200 (CEST) Content-Disposition: inline In-Reply-To: <3C0218D8B3DD114D8DBFE6B68141FBE3185FDCDC@MISOUT7MSGUSRDI.ITServices.sbc.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > Cc: Bernard Iremonger ; > > 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 > > > > Cc: rahul.r.shah@intel.com; wenzhuo.lu@intel.com; dev@dpdk.org; > > > > ZELEZNIAK, ALEX > > > > 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 > > > > > Signed-off-by: Bernard Iremonger > > > > > --- > > > > > 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. > > >