DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
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: [dpdk-dev] [PATCH v3 2/2] ethdev: add hierarchical scheduler API
Date: Wed, 15 Mar 2017 13:43:39 +0100	[thread overview]
Message-ID: <106399437.xFH6ZF6NRJ@xps13> (raw)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265275E105@IRSMSX108.ger.corp.intel.com>

2017-03-10 18:37, Dumitrescu, Cristian:
> From: O'Driscoll, Tim

> > > > OK I better understand now.
> > > > You should add this level of explanation in your patch.
> > > >
> > > > However I am reluctant to add an API if there is no user.
> > > > I think we should wait to have at least one existing driver
> > > implementing
> > > > this API before integrating it.
> > > > It was the approach of eventdev which has a dedicated next- tree.
> > >
> > > The next-tree solution could work, but IMO is not the best for this
> > > case, as this is purely driver development. This is just a TX offload
> > > feature that is well understood, as opposed to a new library with a huge
> > > design effort required like eventdev.
> > >
> > > I think we are reasonably close to get agreement on the API from Cavium,
> > > Intel and NXP. When this is done, how about including it in DPDK with
> > > the experimental tag attached to it until several drivers implement it?
> > >
> > > From Intel side, there are solid plans to implement it for ixgbe and
> > > i40e drivers in next DPDK releases, I am CC-ing Tim to confirm this.
> > 
> > That's correct. We plan to add support for this in the ixgbe and i40e drivers in
> > 17.08.
> 
> 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.

> IMO this approach has the advantage of showing that API agreement has been reached and driver development is in progress. Having it in DPDK is also a better way to advertise this API to the developers that would otherwise be unaware about this effort.

IMO we can advertise a work in progress in a side branch.

  reply	other threads:[~2017-03-15 12:43 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 [this message]
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
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=106399437.xFH6ZF6NRJ@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=balasubramanian.manoharan@cavium.com \
    --cc=bruce.richardson@intel.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=keith.wiles@intel.com \
    --cc=shreyansh.jain@nxp.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).