From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API
Date: Thu, 16 Mar 2017 17:40:37 +0000
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891265276121D@IRSMSX108.ger.corp.intel.com>
References: <1488589820-206947-1-git-send-email-cristian.dumitrescu@intel.com>
 <106399437.xFH6ZF6NRJ@xps13>
 <3EB4FA525960D640B5BDFFD6A3D8912652761170@IRSMSX108.ger.corp.intel.com>
 <4544430.1vcQTJXfeh@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "O'Driscoll, Tim" <tim.odriscoll@intel.com>, "dev@dpdk.org"
 <dev@dpdk.org>, "jerin.jacob@caviumnetworks.com"
 <jerin.jacob@caviumnetworks.com>, "balasubramanian.manoharan@cavium.com"
 <balasubramanian.manoharan@cavium.com>, "hemant.agrawal@nxp.com"
 <hemant.agrawal@nxp.com>, "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>,
 "Wiles, Keith" <keith.wiles@intel.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id C907E1075
 for <dev@dpdk.org>; Thu, 16 Mar 2017 18:40:40 +0100 (CET)
In-Reply-To: <4544430.1vcQTJXfeh@xps13>
Content-Language: en-US
List-Id: DPDK patches and discussions <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>



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, March 16, 2017 5:30 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>; dev@dpdk.org;
> jerin.jacob@caviumnetworks.com;
> balasubramanian.manoharan@cavium.com; hemant.agrawal@nxp.com;
> shreyansh.jain@nxp.com; Wiles, Keith <keith.wiles@intel.com>; Richardson,
> Bruce <bruce.richardson@intel.com>
> Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API
>=20
> 2017-03-16 16:23, Dumitrescu, Cristian:
> > ... <snip>
> >
> > > > Thomas, given Tim's confirmation of Intel's plans to implement this=
 API
> for
> > > the ixgbe and i40e drivers in DPDK release 17.8, are you in favour of
> including
> > > this API in 17.5 with experimental tag (subject to full API agreement=
 being
> > > reached)?
> > >
> > > I think starting a branch in a dedicated "next" repo is a better appr=
oach.
> > > rte_flow and eventdev were (and will be) integrated only when at leas=
t
> one
> > > hardware device is supported.
> > > I suggest to follow the same workflow.
> > >
> >
> > Thomas, if this is the only path forward you are willing to support, th=
en let's
> go this way, but let's make sure we are all on the same page with the ter=
ms
> and conditions that apply.
> >
> > Do you agree now to merge this next-tree to DPDK once this API is
> implemented for at least one PMD? We would like to avoid getting any last
> minute objections from you or anybody else on the fundamentals; if you
> have any, please let's discuss them now.
>=20
> At least one "hardware" PMD, yes. It would prove the API can work for rea=
l.
> About accepting it definitely in a given release, it will be checked
> with the technical board on Monday.
>=20

OK, great, thank you. Is the agenda of the technical board meetings publish=
ed in advance somewhere?


> > How do we manage the API freeze on the next-tree? Once the API is
> agreed, we would like to freeze it so the driver development can proceed;
> we can then do some reasonably small changes to the API based on the
> learnings we get during driver development. We would like to welcome any
> parties interested in contributing to join Cavium, Intel and NXP in this =
effort,
> but we would like to avoid any last minute major API change requests.
>=20
> You are taking it the wrong way. Your main concern is to not be disturbed
> with change requests. It should be the contrary: you have a chance to
> work with other vendors to test and improve the API.
> You should embrace this chance and delay the API freeze as much as
> possible.

Not really. We definitely welcome change requests done in a timely manner. =
My concern is about last minute change requests, such as major API change r=
equests just a few days before the release when driver development is compl=
ete. Is there a policy in place to prevent against such events for next-tre=
e type of development?