DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kinsella, Ray" <mdr@ashroe.eu>
To: Thomas Monjalon <thomas@monjalon.net>, dev@dpdk.org
Cc: olivier.matz@6wind.com, Neil Horman <nhorman@tuxdriver.com>,
	John McNamara <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>
Subject: Re: [dpdk-dev] [PATCH] doc: announce API change in mbuf
Date: Wed, 5 Aug 2020 10:28:21 +0100	[thread overview]
Message-ID: <2b245241-5e09-49c4-daf2-79803788615d@ashroe.eu> (raw)
In-Reply-To: <20200731160349.3198317-1-thomas@monjalon.net>



On 31/07/2020 17:03, Thomas Monjalon wrote:
> In order to prepare for adding more features requiring more space in mbuf,
> some static fields must become dynamic.
> Some small layout changes may have performance benefits as well.
> 
> The deprecation notice for atomic refcount is moved and reworded
> to fit below the layout deprecation.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  doc/guides/rel_notes/deprecation.rst | 26 ++++++++++++++++++++------
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ea4cfa7a48..015c386c76 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -67,6 +67,26 @@ Deprecation Notices
>    us extending existing enum/define.
>    One solution can be using a fixed size array instead of ``.*MAX.*`` value.
>  
> +* mbuf: Some fields will be converted to dynamic API in DPDK 20.11
> +  in order to reserve more space for the dynamic fields.
> +  The following static fields will be moved as dynamic:
> +
> +  - ``timestamp``
> +  - ``userdata`` / ``udata64``
> +  - ``seqn``
> +
> +  As a consequence, the layout of the ``struct rte_mbuf`` will be re-arranged,
> +  avoiding impact on vectorized implementation of the driver datapaths,
> +  while evaluating performance gains of a better use of the first cache line.
> +
> +  The deprecated unioned fields ``buf_physaddr`` and ``refcnt_atomic``
> +  (as explained below) will be removed in DPDK 20.11.

So what does anyone using these fields do - except panic perhaps.
Can we include a reference to the DPDK Userspace presentation, 
in advance of the documentation supporting the dynamic mbuf.
To prepare people for what is to come ... 

https://www.youtube.com/watch?v=Ttl6MlhmzWY

> +
> +* mbuf: ``refcnt_atomic`` member in structures ``rte_mbuf`` and
> +  ``rte_mbuf_ext_shared_info`` is of type ``rte_atomic16_t``.
> +  Due to adoption of C11 atomic builtins, the field ``refcnt_atomic``
> +  will be replaced with ``refcnt`` of type ``uint16_t`` in DPDK 20.11.
> +
>  * ethdev: Split the ``struct eth_dev_ops`` struct to hide it as much as possible
>    will be done in 20.11.
>    Currently the ``struct eth_dev_ops`` struct is accessible by the application
> @@ -132,12 +152,6 @@ Deprecation Notices
>    in "rte_sched.h". These changes are aligned to improvements suggested in the
>    RFC https://mails.dpdk.org/archives/dev/2018-November/120035.html.
>  
> -* mbuf: ``refcnt_atomic`` member in structures ``rte_mbuf`` and
> -  ``rte_mbuf_ext_shared_info`` is of type ``rte_atomic16_t``. Due to adoption
> -  of C11 atomic builtins it will be of type ``uint16_t``. ``refcnt_atomic``
> -  will be removed in 20.11. It will be replaced with ``refcnt`` of type
> -  ``uint16_t``.
> -
>  * metrics: The function ``rte_metrics_init`` will have a non-void return
>    in order to notify errors instead of calling ``rte_exit``.
>  
> 

  parent reply	other threads:[~2020-08-05  9:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 16:03 Thomas Monjalon
2020-08-02 19:28 ` Olivier Matz
2020-08-03 12:43   ` Andrew Rybchenko
2020-08-03 14:25 ` David Marchand
2020-08-05  9:28 ` Kinsella, Ray [this message]
2020-08-06  0:07   ` Thomas Monjalon
  -- strict thread matches above, loose matches on Subject: below --
2019-08-01 12:41 Thomas Monjalon
2019-08-04 21:33 ` Olivier Matz
2019-08-05  8:05 ` Andrew Rybchenko
2019-08-05 10:14   ` Thomas Monjalon

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=2b245241-5e09-49c4-daf2-79803788615d@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=nhorman@tuxdriver.com \
    --cc=olivier.matz@6wind.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).