From: Thomas Monjalon <thomas@monjalon.net>
To: Olivier MATZ <olivier.matz@6wind.com>, Ivan Boule <ivan.boule@6wind.com>
Cc: dev@dpdk.org, john.mcnamara@intel.com
Subject: Re: [dpdk-dev] [PATCH] doc: announce API change for ethdev port info
Date: Wed, 15 Nov 2017 16:23:56 +0100 [thread overview]
Message-ID: <23246243.WUkuQapCU8@xps> (raw)
In-Reply-To: <20171115081327.gzr2rzhpftcu5hn2@platinum>
15/11/2017 09:13, Olivier MATZ:
> On Wed, Nov 15, 2017 at 12:50:55AM +0100, Thomas Monjalon wrote:
> > 16/10/2017 16:27, Ivan Boule:
> > > To help administrative tasks on ports, new per-port information need
> > > to be added into the data structure rte_eth_dev_info supplied by the
> > > dev_infos_get() function exported by a Poll Mode Driver.
> > >
> > > See http://dpdk.org/ml/archives/dev/2017-September/074885.html for
> > > details.
> > >
> > > Signed-off-by: Ivan Boule <ivan.boule@6wind.com>
> > > Acked-by: Olivier Matz <olivier.matz@6wind.com>
> > > ---
> > > +* librte_ether: additional fields will be added into the ``rte_eth_dev_info``
> > > + structure in 18.02, breaking the API. These fields will contain:
> > > +
> > > + - the set of supported link modes,
> > > + - the set of advertised link modes,
> > > + - the type of port connector,
> > > + - autonegotiation enabled or not.
> >
> > This patch is not accepted in 17.11 for following reasons:
> > - it requires at least 3 acks
> > - we are not going to break API in 18.02, except maybe for EAL devargs
> > - the link mode is redundant with the speed capabilities
> > - such fields require work (and time) for every PMD to be fully supported
> > - we should discuss more generally which infos are in the scope of this function
> >
> > Sorry for the short notice, I was waiting for comments and to see if
> > other deprecations were sent (or not) for ethdev.
>
> Thomas, be aware that it's very frustrating to have this kind feedback 9
> weeks after the submission of the RFC, and few days before the release.
Yes, sure I know how it can be frustrating and I am sorry about that.
I forgot to review the RFC and I forgot to comment this deprecation notice.
Then it was pending like other deprecation notices, but no new deprecation
notice appeared for 18.02, and nobody did a comment on those patches.
So I think it is better to just postpone it for 18.05.
Anyway we can comment and work on the RFC in the meantime.
next prev parent reply other threads:[~2017-11-15 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 14:27 Ivan Boule
2017-11-14 23:50 ` Thomas Monjalon
2017-11-15 8:13 ` Olivier MATZ
2017-11-15 15:23 ` Thomas Monjalon [this message]
2018-02-13 13:15 ` Olivier Matz
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=23246243.WUkuQapCU8@xps \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=ivan.boule@6wind.com \
--cc=john.mcnamara@intel.com \
--cc=olivier.matz@6wind.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).