Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config

[David Marchand <david.marchand@redhat.com>]

On Thu, May 9, 2019 at 8:53 PM Erik Gabriel Carrillo <
erik.g.carrillo@intel.com> wrote:

> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI.  Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v2:
>  - Original deprecation notice announced a change to the rte_mem_config
>    struct that would break ABI.  Update the notice to instead announce
>    the struct will be made private.  (Stephen, Anatoly, David)
>
>  doc/guides/rel_notes/deprecation.rst | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
>      + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it
> from the
> +  externally visible ABI and allow it to be updated in the future.
> +
>  * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
>    have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
>    functions.  The due date for the removal targets DPDK 20.02.
> --
> 2.6.4
>
>
I had a look at the current callers, trying to see what "hiding" means.

$ git grep -Elw '(rte_mem_config|mem_config)' origin/master --
origin/master:app/test/test_memzone.c
origin/master:doc/guides/rel_notes/release_18_11.rst
origin/master:drivers/bus/fslmc/fslmc_vfio.c
origin/master:drivers/net/ena/ena_ethdev.c
origin/master:drivers/net/mlx4/mlx4_mr.c
origin/master:drivers/net/mlx5/mlx5_mr.c
origin/master:drivers/net/virtio/virtio_user/virtio_user_dev.c
origin/master:lib/librte_eal/common/eal_common_memory.c
origin/master:lib/librte_eal/common/eal_common_memzone.c
origin/master:lib/librte_eal/common/eal_common_tailqs.c
origin/master:lib/librte_eal/common/include/rte_eal.h
origin/master:lib/librte_eal/common/include/rte_eal_memconfig.h
origin/master:lib/librte_eal/common/malloc_heap.c
origin/master:lib/librte_eal/common/rte_malloc.c
origin/master:lib/librte_eal/freebsd/eal/eal.c
origin/master:lib/librte_eal/freebsd/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal.c
origin/master:lib/librte_eal/linux/eal/eal_memalloc.c
origin/master:lib/librte_eal/linux/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal_vfio.c

- I understand that the following drivers will need a new lock/unlock api
to protect calls to the memory api.
drivers/bus/fslmc/fslmc_vfio.c
drivers/net/mlx4/mlx4_mr.c
drivers/net/mlx5/mlx5_mr.c
drivers/net/virtio/virtio_user/virtio_user_dev.c

- I have a little trouble with this one, so there might be a new api for
this driver usecase.
A discussion will have to happen with its maintainers (added in CC:).
drivers/net/ena/ena_ethdev.c


Apart from this, I am ok with the objective, which is to hide one more eal
internal structure.

Acked-by: David Marchand <david.marchand@redhat.com>


-- 
David Marchand