DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Chautru, Nicolas" <nicolas.chautru@intel.com>,
	David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [20.11, PATCH] bbdev: remove experimental tag from API
Date: Thu, 2 Jul 2020 18:09:27 +0000	[thread overview]
Message-ID: <VI1PR04MB31682722F66690622C13DF53E66D0@VI1PR04MB3168.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <BY5PR11MB4451ED394915F5E3B6D3A254F86D0@BY5PR11MB4451.namprd11.prod.outlook.com>

> 
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > > > Hello Nicolas,
> > > >
> > > > On Sat, Jun 27, 2020 at 1:14 AM Nicolas Chautru
> > > > <nicolas.chautru@intel.com> wrote:
> > > > >
> > > > > Planning to move bbdev API to stable from 20.11 (ABI version 21)
> > > > > and remove experimental tag.
> > > > > Sending now to advertise and get any feedback.
> > > > > Some manual rebase will be required later on notably as the actual
> > > > > release note which is not there yet.
> > > >
> > > > Cool that we want to stabilize this API.
> > > > My concern is that we have drivers from a single vendor.
> > > > I would hate to see a new vendor unable to submit a driver (or
> > > > having to wait until the next ABI breakage window) because of the
> > > > current API/ABI.
> > > >
> > > >
> > >
> > > +1 from my side. I am not sure how much it is acceptable for all the
> > > vendors/customers.
> > > It is not reviewed by most of the vendors who may support in future.
> > > It is not good to remove experimental tag as we have a long 1 year
> > > cycle to break the API/ABI.
> > >
> > Moving the patch as deferred in patchworks.
> 
> That is fine and all good discussion.
> We know of another vendor who plan to release a bbdev driver but probably
> after 20.11.
> There is one extra capability they will need exposed, we will aim to have the API
> is updated prior to that.
> Assuming the API get updated between now and 20.11, is there still room to
> remove experimental tag in 20.11 or the expectation is to wait regardless for a
> full stable cycle and only intercept ABI v22 in  21.11?
> 
I think ABI v22 in 21.11 would be good to move this to stable so that if there are changes
In the ABI when a new vendor PMD comes up, they can be incorporated.
And as the world is evolving towards 5G, there may be multiple vendors and ABI may change.

      reply	other threads:[~2020-07-02 18:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-26 23:14 Nicolas Chautru
2020-06-26 23:14 ` Nicolas Chautru
2020-06-30  7:30 ` David Marchand
2020-06-30  7:35   ` Akhil Goyal
2020-07-02 17:54     ` Akhil Goyal
2020-07-02 18:02       ` Chautru, Nicolas
2020-07-02 18:09         ` Akhil Goyal [this message]

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=VI1PR04MB31682722F66690622C13DF53E66D0@VI1PR04MB3168.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=nicolas.chautru@intel.com \
    --cc=thomas@monjalon.net \
    /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).