From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id C405A590E for ; Thu, 22 Sep 2016 13:25:26 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 22 Sep 2016 04:25:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,378,1470726000"; d="scan'208";a="1054789037" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2016 04:25:24 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.164]) by irsmsx105.ger.corp.intel.com ([169.254.7.196]) with mapi id 14.03.0248.002; Thu, 22 Sep 2016 12:25:07 +0100 From: "Iremonger, Bernard" To: Jerin Jacob , Thomas Monjalon CC: "Shah, Rahul R" , "Lu, Wenzhuo" , "dev@dpdk.org" , "ZELEZNIAK, ALEX" Thread-Topic: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions Thread-Index: AQHR/3nK2iF9QXzaW0mqFbQ2s9ydhaBxOCIAgAAnj4CABcb8AIAAWXeAgAFmTYCADJ72UA== 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> In-Reply-To: <20160914112811.GA8364@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTIwNTY2M2MtN2UwNi00NjRjLWE2NDUtM2E3OWVjMDM3NzlkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InoxUjU1K0pxcHNrNHFqUWVmODJhUjdjUXNNTVFsU1U3cUEzSE5hb0c4TE09In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH v2 1/5] librte_ether: add internal callback functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 11:25:27 -0000 Hi Jerin, Thomas, > -----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 > > > 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 =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. > > > >