From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
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>,
"techboard@dpdk.org" <techboard@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API
Date: Thu, 16 Mar 2017 19:06:39 +0000 [thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912652761294@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <3089139.1r3dZqkNdq@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, March 16, 2017 6:11 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Ananyev,
> Konstantin <konstantin.ananyev@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>; techboard@dpdk.org
> Subject: Re: [PATCH v3 2/2] ethdev: add hierarchical scheduler API
>
> 2017-03-16 17:40, Dumitrescu, Cristian:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 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
> approach.
> > > > > rte_flow and eventdev were (and will be) integrated only when at
> least
> > > 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, then
> let's
> > > go this way, but let's make sure we are all on the same page with the
> terms
> > > 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.
> > >
> > > At least one "hardware" PMD, yes. It would prove the API can work for
> real.
> > > About accepting it definitely in a given release, it will be checked
> > > with the technical board on Monday.
> > >
> >
> > OK, great, thank you. Is the agenda of the technical board meetings
> published in advance somewhere?
>
> For the previous meeting, it was published:
> https://bimestriel.framapad.org/p/r.a5199d22813a5ac79d1d365b9ce
> cb905
> For the next one, please Konstantin, could you publish the agenda on a pad?
>
> > > > 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.
> > >
> > > 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 requests just a few days before the release when driver
> development is complete. Is there a policy in place to prevent against such
> events for next-tree type of development?
>
> No there is no such policy on a next- tree.
> It is free to the maintainer of the tree I guess.
Thanks, Thomas. Can you please create a next-tree for QoS Traffic Management with the following details:
Maintainer: Cristian
Committers: Hemant, Jerin, Cristian
next prev parent reply other threads:[~2017-03-16 19:06 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 1:10 [dpdk-dev] [PATCH v3 0/2] ethdev: abstraction layer for QoS hierarchical scheduler Cristian Dumitrescu
2017-03-04 1:10 ` [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API Cristian Dumitrescu
2017-03-06 10:32 ` Thomas Monjalon
2017-03-06 16:35 ` Dumitrescu, Cristian
2017-03-06 16:57 ` Thomas Monjalon
2017-03-06 18:28 ` Dumitrescu, Cristian
2017-03-06 20:21 ` Thomas Monjalon
2017-03-06 20:41 ` Wiles, Keith
2017-03-06 20:54 ` Stephen Hemminger
2017-03-07 10:14 ` Dumitrescu, Cristian
2017-03-07 12:56 ` Thomas Monjalon
2017-03-07 19:17 ` Wiles, Keith
2017-03-06 16:36 ` Dumitrescu, Cristian
2017-05-19 17:12 ` [dpdk-dev] [PATCH v4 0/2] ethdev: abstraction layer for QoS traffic management Cristian Dumitrescu
2017-05-19 17:12 ` [dpdk-dev] [PATCH v4 1/2] ethdev: add traffic management ops get API Cristian Dumitrescu
2017-06-09 16:51 ` [dpdk-dev] [PATCH v5 0/2] ethdev: abstraction layer for QoS traffic management Cristian Dumitrescu
2017-06-09 16:51 ` [dpdk-dev] [PATCH v5 1/2] ethdev: add traffic management ops get API Cristian Dumitrescu
2017-06-09 16:51 ` [dpdk-dev] [PATCH v5 2/2] ethdev: add traffic management API Cristian Dumitrescu
2017-06-12 3:36 ` Jerin Jacob
2017-06-12 10:24 ` Dumitrescu, Cristian
2017-06-12 13:35 ` [dpdk-dev] [PATCH v6 0/2] ethdev: abstraction layer for QoS traffic management Cristian Dumitrescu
2017-06-12 13:35 ` [dpdk-dev] [PATCH v6 1/2] ethdev: add traffic management ops get API Cristian Dumitrescu
2017-06-12 13:35 ` [dpdk-dev] [PATCH v6 2/2] ethdev: add traffic management API Cristian Dumitrescu
2017-06-27 13:24 ` [dpdk-dev] [PATCH v6 0/2] ethdev: abstraction layer for QoS traffic management Dumitrescu, Cristian
2017-05-19 17:12 ` [dpdk-dev] [PATCH v4 2/2] ethdev: add traffic management API Cristian Dumitrescu
2017-05-19 17:34 ` Stephen Hemminger
2017-05-22 14:25 ` Dumitrescu, Cristian
2017-05-24 11:28 ` Hemant Agrawal
2017-05-31 13:45 ` Jerin Jacob
2017-05-31 17:05 ` Manoharan, Balasubramanian
2017-03-04 1:10 ` [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API Cristian Dumitrescu
2017-03-06 10:38 ` Thomas Monjalon
2017-03-06 16:59 ` Dumitrescu, Cristian
2017-03-06 20:07 ` Thomas Monjalon
2017-03-07 19:29 ` Dumitrescu, Cristian
2017-03-08 9:51 ` O'Driscoll, Tim
2017-03-10 18:37 ` Dumitrescu, Cristian
2017-03-15 12:43 ` Thomas Monjalon
2017-03-16 16:23 ` Dumitrescu, Cristian
2017-03-16 17:29 ` Thomas Monjalon
2017-03-16 17:40 ` Dumitrescu, Cristian
2017-03-16 18:10 ` Thomas Monjalon
2017-03-16 19:06 ` Dumitrescu, Cristian [this message]
2017-03-24 19:55 ` Dumitrescu, Cristian
2017-03-06 16:15 ` Stephen Hemminger
2017-03-06 18:17 ` Dumitrescu, Cristian
2017-03-16 17:35 ` Thomas Monjalon
2017-03-30 10:32 ` Hemant Agrawal
2017-04-07 16:51 ` Dumitrescu, Cristian
2017-04-07 13:20 ` Jerin Jacob
2017-04-07 17:47 ` Dumitrescu, Cristian
2017-04-10 14:00 ` Jerin Jacob
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EB4FA525960D640B5BDFFD6A3D8912652761294@IRSMSX108.ger.corp.intel.com \
--to=cristian.dumitrescu@intel.com \
--cc=balasubramanian.manoharan@cavium.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=keith.wiles@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=shreyansh.jain@nxp.com \
--cc=techboard@dpdk.org \
--cc=thomas.monjalon@6wind.com \
--cc=tim.odriscoll@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).