doc: announce API change in mbuf

Message ID 20190801124123.21591-1-thomas@monjalon.net (mailing list archive)
State Rejected, archived
Delegated to: Thomas Monjalon
Headers
Series doc: announce API change in mbuf |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Thomas Monjalon Aug. 1, 2019, 12:41 p.m. UTC
  In order to prepare for a long term stable API, the mbuf library
has to change: allowing more features as dynamic fields,
and fixing the lack of rte_ prefix in the namespace.
The namespace fix should not break the compatibility by keeping
some aliases during few releases to give time for migration.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 doc/guides/rel_notes/deprecation.rst | 5 +++++
 1 file changed, 5 insertions(+)
  

Comments

Olivier Matz Aug. 4, 2019, 9:33 p.m. UTC | #1
On Thu, Aug 01, 2019 at 02:41:23PM +0200, Thomas Monjalon wrote:
> In order to prepare for a long term stable API, the mbuf library
> has to change: allowing more features as dynamic fields,
> and fixing the lack of rte_ prefix in the namespace.
> The namespace fix should not break the compatibility by keeping
> some aliases during few releases to give time for migration.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

Thanks Thomas for sending the deprecation notice.

Acked-by: Olivier Matz <olivier.matz@6wind.com>
  
Andrew Rybchenko Aug. 5, 2019, 8:05 a.m. UTC | #2
On 8/1/19 3:41 PM, Thomas Monjalon wrote:
> In order to prepare for a long term stable API, the mbuf library
> has to change: allowing more features as dynamic fields,
> and fixing the lack of rte_ prefix in the namespace.
> The namespace fix should not break the compatibility by keeping
> some aliases during few releases to give time for migration.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>   doc/guides/rel_notes/deprecation.rst | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 37b8592b6..e4939f1fe 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -51,6 +51,11 @@ Deprecation Notices
>     structure would be made internal (or removed if all dependencies are cleared)
>     in future releases.
>   
> +* mbuf: Some fields will be moved or converted to dynamic API in DPDK 19.11
> +  in order to offer more space for the dynamic fields in future.
> +  The namespace will be fixed at the same time while keeping a backward
> +  compatibility for some time.
> +
>   * ethdev: the legacy filter API, including
>     ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
>     as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,

The deprecation notice is better than nothing, but "some fields" is
hardly useful since it doe not provide enough information if an
application is affected or not.

Also we have no yet information on performance impact of
switching to dynamic fields.

May be it is not a problem if switching does not happen.

I have no strong opinion, just trying to raise my concerns.
May be you already have answers on it.
  
Thomas Monjalon Aug. 5, 2019, 10:14 a.m. UTC | #3
05/08/2019 10:05, Andrew Rybchenko:
> On 8/1/19 3:41 PM, Thomas Monjalon wrote:
> > In order to prepare for a long term stable API, the mbuf library
> > has to change: allowing more features as dynamic fields,
> > and fixing the lack of rte_ prefix in the namespace.
> > The namespace fix should not break the compatibility by keeping
> > some aliases during few releases to give time for migration.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
[..]
> > +* mbuf: Some fields will be moved or converted to dynamic API in DPDK 19.11
> > +  in order to offer more space for the dynamic fields in future.
> > +  The namespace will be fixed at the same time while keeping a backward
> > +  compatibility for some time.
> 
> The deprecation notice is better than nothing, but "some fields" is
> hardly useful since it doe not provide enough information if an
> application is affected or not.
> 
> Also we have no yet information on performance impact of
> switching to dynamic fields.
> 
> May be it is not a problem if switching does not happen.
> 
> I have no strong opinion, just trying to raise my concerns.
> May be you already have answers on it.

Unfortunately I don't have answers because I did not start this work.
We will have to evaluate the impact and discuss what to move or not.
  

Patch

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 37b8592b6..e4939f1fe 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -51,6 +51,11 @@  Deprecation Notices
   structure would be made internal (or removed if all dependencies are cleared)
   in future releases.
 
+* mbuf: Some fields will be moved or converted to dynamic API in DPDK 19.11
+  in order to offer more space for the dynamic fields in future.
+  The namespace will be fixed at the same time while keeping a backward
+  compatibility for some time.
+
 * ethdev: the legacy filter API, including
   ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
   as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,