From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Iremonger, Bernard" <bernard.iremonger@intel.com>
Subject: Re: [RFC PATCH v2 1/5] librte_ether: add internal
 callback functions
Date: Thu, 22 Sep 2016 11:25:07 +0000
Message-ID: <8CEF83825BEC744B83065625E567D7C21A08C411@IRSMSX108.ger.corp.intel.com>
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>
 <20160914112811.GA8364@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "Shah, Rahul R" <rahul.r.shah@intel.com>, "Lu, Wenzhuo"
 <wenzhuo.lu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "ZELEZNIAK, ALEX"
 <az5157@att.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Thomas Monjalon
 <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id C405A590E
 for <dev@dpdk.org>; Thu, 22 Sep 2016 13:25:26 +0200 (CEST)
In-Reply-To: <20160914112811.GA8364@localhost.localdomain>
Content-Language: en-US
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Jerin, Thomas,

<snip>

> -----Original Message-----
> Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal
> callback functions
>=20
> 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.
>=20
> 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 th=
is
> 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 th=
e
> ethdev spec is not a good idea.

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

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 =3D *cb_lst;
> > > > > >  		cb_lst->active =3D 1;
> > > > > > +		if (param !=3D NULL)
> > > > > > +			dev_cb.cb_arg =3D (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 definiti=
ons.
> > > >