[dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Erik Gabriel Carrillo]

Due to an upcoming fix to allow the timer library to safely free its
allocations during the finalize() call[1], an ABI change will be
required. A new lock will be added to the rte_mem_config structure,
which will be used by the timer library to synchronize init/finalize
calls among multiple processes.

[1] http://patches.dpdk.org/patch/53334/

Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..7551383 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,10 @@ Deprecation Notices
 
     + ``rte_eal_devargs_type_count``
 
+* eal: the ``rte_mem_config`` struct will change to include a new lock that
+  will allow the timer subsystem to safely release its allocations at cleanup
+  time. This will result in an ABI break.
+
 * 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

[dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Erik Gabriel Carrillo]

Due to an upcoming fix to allow the timer library to safely free its
allocations during the finalize() call[1], an ABI change will be
required. A new lock will be added to the rte_mem_config structure,
which will be used by the timer library to synchronize init/finalize
calls among multiple processes.

[1] http://patches.dpdk.org/patch/53334/

Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..7551383 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,10 @@ Deprecation Notices
 
     + ``rte_eal_devargs_type_count``
 
+* eal: the ``rte_mem_config`` struct will change to include a new lock that
+  will allow the timer subsystem to safely release its allocations at cleanup
+  time. This will result in an ABI break.
+
 * 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

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Wed,  8 May 2019 17:48:06 -0500
Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:

> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
> 
> [1] http://patches.dpdk.org/patch/53334/
> 
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..7551383 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,10 @@ Deprecation Notices
>  
>      + ``rte_eal_devargs_type_count``
>  
> +* eal: the ``rte_mem_config`` struct will change to include a new lock that
> +  will allow the timer subsystem to safely release its allocations at cleanup
> +  time. This will result in an ABI break.
> +
>  * 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.

NAK

Please go to the effort of making rte_mem_config not part of the visible ABI.
Then change it.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Wed,  8 May 2019 17:48:06 -0500
Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:

> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
> 
> [1] http://patches.dpdk.org/patch/53334/
> 
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..7551383 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,10 @@ Deprecation Notices
>  
>      + ``rte_eal_devargs_type_count``
>  
> +* eal: the ``rte_mem_config`` struct will change to include a new lock that
> +  will allow the timer subsystem to safely release its allocations at cleanup
> +  time. This will result in an ABI break.
> +
>  * 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.

NAK

Please go to the effort of making rte_mem_config not part of the visible ABI.
Then change it.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[David Marchand]

On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger <stephen@networkplumber.org>
wrote:

> On Wed,  8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > index b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> >      + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a new lock
> that
> > +  will allow the timer subsystem to safely release its allocations at
> cleanup
> > +  time. This will result in an ABI break.
> > +
> >  * 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.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the visible
> ABI.
> Then change it.
>

+1.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[David Marchand]

On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger <stephen@networkplumber.org>
wrote:

> On Wed,  8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> > ---
> >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > index b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> >      + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a new lock
> that
> > +  will allow the timer subsystem to safely release its allocations at
> cleanup
> > +  time. This will result in an ABI break.
> > +
> >  * 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.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the visible
> ABI.
> Then change it.
>

+1.


-- 
David Marchand

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 8:05 AM, David Marchand wrote:
> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger 
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> 
>     On Wed,  8 May 2019 17:48:06 -0500
>     Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>     <mailto:erik.g.carrillo@intel.com>> wrote:
> 
>      > Due to an upcoming fix to allow the timer library to safely free its
>      > allocations during the finalize() call[1], an ABI change will be
>      > required. A new lock will be added to the rte_mem_config structure,
>      > which will be used by the timer library to synchronize init/finalize
>      > calls among multiple processes.
>      >
>      > [1] http://patches.dpdk.org/patch/53334/
>      >
>      > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>     <mailto:erik.g.carrillo@intel.com>>
>      > ---
>      >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>      >  1 file changed, 4 insertions(+)
>      >
>      > diff --git a/doc/guides/rel_notes/deprecation.rst
>     b/doc/guides/rel_notes/deprecation.rst
>      > index b47c8c2..7551383 100644
>      > --- a/doc/guides/rel_notes/deprecation.rst
>      > +++ b/doc/guides/rel_notes/deprecation.rst
>      > @@ -31,6 +31,10 @@ Deprecation Notices
>      >
>      >      + ``rte_eal_devargs_type_count``
>      >
>      > +* eal: the ``rte_mem_config`` struct will change to include a
>     new lock that
>      > +  will allow the timer subsystem to safely release its
>     allocations at cleanup
>      > +  time. This will result in an ABI break.
>      > +
>      >  * 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.
> 
>     NAK
> 
>     Please go to the effort of making rte_mem_config not part of the
>     visible ABI.
>     Then change it.
> 
> 
> +1.

I agree on principle, however this won't solve the issue. It doesn't 
need to be externally visible, but that's not all of its problems - it's 
also shared between processes so there's an ABI contract between primary 
and secondary too. This means that, even if the structure itself is not 
public, any changes to it will still result in an ABI break. That's the 
nature of our shared memory.

In other words, if your goal is to avoid ABI breaks on changing this 
structure, making it internal won't help in the slightest.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 8:05 AM, David Marchand wrote:
> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger 
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> 
>     On Wed,  8 May 2019 17:48:06 -0500
>     Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>     <mailto:erik.g.carrillo@intel.com>> wrote:
> 
>      > Due to an upcoming fix to allow the timer library to safely free its
>      > allocations during the finalize() call[1], an ABI change will be
>      > required. A new lock will be added to the rte_mem_config structure,
>      > which will be used by the timer library to synchronize init/finalize
>      > calls among multiple processes.
>      >
>      > [1] http://patches.dpdk.org/patch/53334/
>      >
>      > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>     <mailto:erik.g.carrillo@intel.com>>
>      > ---
>      >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>      >  1 file changed, 4 insertions(+)
>      >
>      > diff --git a/doc/guides/rel_notes/deprecation.rst
>     b/doc/guides/rel_notes/deprecation.rst
>      > index b47c8c2..7551383 100644
>      > --- a/doc/guides/rel_notes/deprecation.rst
>      > +++ b/doc/guides/rel_notes/deprecation.rst
>      > @@ -31,6 +31,10 @@ Deprecation Notices
>      >
>      >      + ``rte_eal_devargs_type_count``
>      >
>      > +* eal: the ``rte_mem_config`` struct will change to include a
>     new lock that
>      > +  will allow the timer subsystem to safely release its
>     allocations at cleanup
>      > +  time. This will result in an ABI break.
>      > +
>      >  * 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.
> 
>     NAK
> 
>     Please go to the effort of making rte_mem_config not part of the
>     visible ABI.
>     Then change it.
> 
> 
> +1.

I agree on principle, however this won't solve the issue. It doesn't 
need to be externally visible, but that's not all of its problems - it's 
also shared between processes so there's an ABI contract between primary 
and secondary too. This means that, even if the structure itself is not 
public, any changes to it will still result in an ABI break. That's the 
nature of our shared memory.

In other words, if your goal is to avoid ABI breaks on changing this 
structure, making it internal won't help in the slightest.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Bruce Richardson]

On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 8:05 AM, David Marchand wrote:
> > On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> > <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> > 
> >     On Wed,  8 May 2019 17:48:06 -0500
> >     Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >     <mailto:erik.g.carrillo@intel.com>> wrote:
> > 
> >      > Due to an upcoming fix to allow the timer library to safely free its
> >      > allocations during the finalize() call[1], an ABI change will be
> >      > required. A new lock will be added to the rte_mem_config structure,
> >      > which will be used by the timer library to synchronize init/finalize
> >      > calls among multiple processes.
> >      >
> >      > [1] http://patches.dpdk.org/patch/53334/
> >      >
> >      > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >     <mailto:erik.g.carrillo@intel.com>>
> >      > ---
> >      >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >      >  1 file changed, 4 insertions(+)
> >      >
> >      > diff --git a/doc/guides/rel_notes/deprecation.rst
> >     b/doc/guides/rel_notes/deprecation.rst
> >      > index b47c8c2..7551383 100644
> >      > --- a/doc/guides/rel_notes/deprecation.rst
> >      > +++ b/doc/guides/rel_notes/deprecation.rst
> >      > @@ -31,6 +31,10 @@ Deprecation Notices
> >      >
> >      >      + ``rte_eal_devargs_type_count``
> >      >
> >      > +* eal: the ``rte_mem_config`` struct will change to include a
> >     new lock that
> >      > +  will allow the timer subsystem to safely release its
> >     allocations at cleanup
> >      > +  time. This will result in an ABI break.
> >      > +
> >      >  * 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.
> > 
> >     NAK
> > 
> >     Please go to the effort of making rte_mem_config not part of the
> >     visible ABI.
> >     Then change it.
> > 
> > 
> > +1.
> 
> I agree on principle, however this won't solve the issue. It doesn't need to
> be externally visible, but that's not all of its problems - it's also shared
> between processes so there's an ABI contract between primary and secondary
> too. This means that, even if the structure itself is not public, any
> changes to it will still result in an ABI break. That's the nature of our
> shared memory.
> 
> In other words, if your goal is to avoid ABI breaks on changing this
> structure, making it internal won't help in the slightest.
>

Is there an ABI contract between primary and secondary. I always assumed
that if using secondary processes the requirement (though undocumented) was
that both had to be linked against the exact same versions of DPDK?

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Bruce Richardson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2901 bytes --]

On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 8:05 AM, David Marchand wrote:
> > On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> > <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> > 
> >     On Wed,  8 May 2019 17:48:06 -0500
> >     Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >     <mailto:erik.g.carrillo@intel.com>> wrote:
> > 
> >      > Due to an upcoming fix to allow the timer library to safely free its
> >      > allocations during the finalize() call[1], an ABI change will be
> >      > required. A new lock will be added to the rte_mem_config structure,
> >      > which will be used by the timer library to synchronize init/finalize
> >      > calls among multiple processes.
> >      >
> >      > [1] http://patches.dpdk.org/patch/53334/
> >      >
> >      > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >     <mailto:erik.g.carrillo@intel.com>>
> >      > ---
> >      >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >      >  1 file changed, 4 insertions(+)
> >      >
> >      > diff --git a/doc/guides/rel_notes/deprecation.rst
> >     b/doc/guides/rel_notes/deprecation.rst
> >      > index b47c8c2..7551383 100644
> >      > --- a/doc/guides/rel_notes/deprecation.rst
> >      > +++ b/doc/guides/rel_notes/deprecation.rst
> >      > @@ -31,6 +31,10 @@ Deprecation Notices
> >      >
> >      >      + ``rte_eal_devargs_type_count``
> >      >
> >      > +* eal: the ``rte_mem_config`` struct will change to include a
> >     new lock that
> >      > +  will allow the timer subsystem to safely release its
> >     allocations at cleanup
> >      > +  time. This will result in an ABI break.
> >      > +
> >      >  * 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.
> > 
> >     NAK
> > 
> >     Please go to the effort of making rte_mem_config not part of the
> >     visible ABI.
> >     Then change it.
> > 
> > 
> > +1.
> 
> I agree on principle, however this won't solve the issue. It doesn't need to
> be externally visible, but that's not all of its problems - it's also shared
> between processes so there's an ABI contract between primary and secondary
> too. This means that, even if the structure itself is not public, any
> changes to it will still result in an ABI break. That's the nature of our
> shared memory.
> 
> In other words, if your goal is to avoid ABI breaks on changing this
> structure, making it internal won't help in the slightest.
>

Is there an ABI contract between primary and secondary. I always assumed
that if using secondary processes the requirement (though undocumented) was
that both had to be linked against the exact same versions of DPDK?

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 10:06 AM, Bruce Richardson wrote:
> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>> On 09-May-19 8:05 AM, David Marchand wrote:
>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>
>>>      On Wed,  8 May 2019 17:48:06 -0500
>>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>      <mailto:erik.g.carrillo@intel.com>> wrote:
>>>
>>>       > Due to an upcoming fix to allow the timer library to safely free its
>>>       > allocations during the finalize() call[1], an ABI change will be
>>>       > required. A new lock will be added to the rte_mem_config structure,
>>>       > which will be used by the timer library to synchronize init/finalize
>>>       > calls among multiple processes.
>>>       >
>>>       > [1] http://patches.dpdk.org/patch/53334/
>>>       >
>>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>      <mailto:erik.g.carrillo@intel.com>>
>>>       > ---
>>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>       >  1 file changed, 4 insertions(+)
>>>       >
>>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>      b/doc/guides/rel_notes/deprecation.rst
>>>       > index b47c8c2..7551383 100644
>>>       > --- a/doc/guides/rel_notes/deprecation.rst
>>>       > +++ b/doc/guides/rel_notes/deprecation.rst
>>>       > @@ -31,6 +31,10 @@ Deprecation Notices
>>>       >
>>>       >      + ``rte_eal_devargs_type_count``
>>>       >
>>>       > +* eal: the ``rte_mem_config`` struct will change to include a
>>>      new lock that
>>>       > +  will allow the timer subsystem to safely release its
>>>      allocations at cleanup
>>>       > +  time. This will result in an ABI break.
>>>       > +
>>>       >  * 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.
>>>
>>>      NAK
>>>
>>>      Please go to the effort of making rte_mem_config not part of the
>>>      visible ABI.
>>>      Then change it.
>>>
>>>
>>> +1.
>>
>> I agree on principle, however this won't solve the issue. It doesn't need to
>> be externally visible, but that's not all of its problems - it's also shared
>> between processes so there's an ABI contract between primary and secondary
>> too. This means that, even if the structure itself is not public, any
>> changes to it will still result in an ABI break. That's the nature of our
>> shared memory.
>>
>> In other words, if your goal is to avoid ABI breaks on changing this
>> structure, making it internal won't help in the slightest.
>>
> 
> Is there an ABI contract between primary and secondary. I always assumed
> that if using secondary processes the requirement (though undocumented) was
> that both had to be linked against the exact same versions of DPDK?
> 

The fact that it's undocumented means we can't assume everyone will do 
that :)

If the community agrees that primary/secondary processes should always 
use the same DPDK version (regardless of static/dynamic builds etc.), 
then this problem would probably be solved.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 10:06 AM, Bruce Richardson wrote:
> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>> On 09-May-19 8:05 AM, David Marchand wrote:
>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>
>>>      On Wed,  8 May 2019 17:48:06 -0500
>>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>      <mailto:erik.g.carrillo@intel.com>> wrote:
>>>
>>>       > Due to an upcoming fix to allow the timer library to safely free its
>>>       > allocations during the finalize() call[1], an ABI change will be
>>>       > required. A new lock will be added to the rte_mem_config structure,
>>>       > which will be used by the timer library to synchronize init/finalize
>>>       > calls among multiple processes.
>>>       >
>>>       > [1] http://patches.dpdk.org/patch/53334/
>>>       >
>>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>      <mailto:erik.g.carrillo@intel.com>>
>>>       > ---
>>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>       >  1 file changed, 4 insertions(+)
>>>       >
>>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>      b/doc/guides/rel_notes/deprecation.rst
>>>       > index b47c8c2..7551383 100644
>>>       > --- a/doc/guides/rel_notes/deprecation.rst
>>>       > +++ b/doc/guides/rel_notes/deprecation.rst
>>>       > @@ -31,6 +31,10 @@ Deprecation Notices
>>>       >
>>>       >      + ``rte_eal_devargs_type_count``
>>>       >
>>>       > +* eal: the ``rte_mem_config`` struct will change to include a
>>>      new lock that
>>>       > +  will allow the timer subsystem to safely release its
>>>      allocations at cleanup
>>>       > +  time. This will result in an ABI break.
>>>       > +
>>>       >  * 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.
>>>
>>>      NAK
>>>
>>>      Please go to the effort of making rte_mem_config not part of the
>>>      visible ABI.
>>>      Then change it.
>>>
>>>
>>> +1.
>>
>> I agree on principle, however this won't solve the issue. It doesn't need to
>> be externally visible, but that's not all of its problems - it's also shared
>> between processes so there's an ABI contract between primary and secondary
>> too. This means that, even if the structure itself is not public, any
>> changes to it will still result in an ABI break. That's the nature of our
>> shared memory.
>>
>> In other words, if your goal is to avoid ABI breaks on changing this
>> structure, making it internal won't help in the slightest.
>>
> 
> Is there an ABI contract between primary and secondary. I always assumed
> that if using secondary processes the requirement (though undocumented) was
> that both had to be linked against the exact same versions of DPDK?
> 

The fact that it's undocumented means we can't assume everyone will do 
that :)

If the community agrees that primary/secondary processes should always 
use the same DPDK version (regardless of static/dynamic builds etc.), 
then this problem would probably be solved.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Thomas Monjalon]

09/05/2019 11:37, Burakov, Anatoly:
> On 09-May-19 10:06 AM, Bruce Richardson wrote:
> > On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> >> On 09-May-19 8:05 AM, David Marchand wrote:
> >>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>
> >>>      On Wed,  8 May 2019 17:48:06 -0500
> >>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>      <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>
> >>>       > Due to an upcoming fix to allow the timer library to safely free its
> >>>       > allocations during the finalize() call[1], an ABI change will be
> >>>       > required. A new lock will be added to the rte_mem_config structure,
> >>>       > which will be used by the timer library to synchronize init/finalize
> >>>       > calls among multiple processes.
> >>>       >
> >>>       > [1] http://patches.dpdk.org/patch/53334/
> >>>       >
> >>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>      <mailto:erik.g.carrillo@intel.com>>
> >>>       > ---
> >>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >>>       >  1 file changed, 4 insertions(+)
> >>>       >
> >>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
> >>>      b/doc/guides/rel_notes/deprecation.rst
> >>>       > index b47c8c2..7551383 100644
> >>>       > --- a/doc/guides/rel_notes/deprecation.rst
> >>>       > +++ b/doc/guides/rel_notes/deprecation.rst
> >>>       > @@ -31,6 +31,10 @@ Deprecation Notices
> >>>       >
> >>>       >      + ``rte_eal_devargs_type_count``
> >>>       >
> >>>       > +* eal: the ``rte_mem_config`` struct will change to include a
> >>>      new lock that
> >>>       > +  will allow the timer subsystem to safely release its
> >>>      allocations at cleanup
> >>>       > +  time. This will result in an ABI break.
> >>>       > +
> >>>       >  * 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.
> >>>
> >>>      NAK
> >>>
> >>>      Please go to the effort of making rte_mem_config not part of the
> >>>      visible ABI.
> >>>      Then change it.
> >>>
> >>>
> >>> +1.
> >>
> >> I agree on principle, however this won't solve the issue. It doesn't need to
> >> be externally visible, but that's not all of its problems - it's also shared
> >> between processes so there's an ABI contract between primary and secondary
> >> too. This means that, even if the structure itself is not public, any
> >> changes to it will still result in an ABI break. That's the nature of our
> >> shared memory.
> >>
> >> In other words, if your goal is to avoid ABI breaks on changing this
> >> structure, making it internal won't help in the slightest.
> >>
> > 
> > Is there an ABI contract between primary and secondary. I always assumed
> > that if using secondary processes the requirement (though undocumented) was
> > that both had to be linked against the exact same versions of DPDK?
> > 
> 
> The fact that it's undocumented means we can't assume everyone will do 
> that :)
> 
> If the community agrees that primary/secondary processes should always 
> use the same DPDK version (regardless of static/dynamic builds etc.), 
> then this problem would probably be solved.

+1 to document that primary/secondary with different DPDK versions
is not supported.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Thomas Monjalon]

09/05/2019 11:37, Burakov, Anatoly:
> On 09-May-19 10:06 AM, Bruce Richardson wrote:
> > On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> >> On 09-May-19 8:05 AM, David Marchand wrote:
> >>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>
> >>>      On Wed,  8 May 2019 17:48:06 -0500
> >>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>      <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>
> >>>       > Due to an upcoming fix to allow the timer library to safely free its
> >>>       > allocations during the finalize() call[1], an ABI change will be
> >>>       > required. A new lock will be added to the rte_mem_config structure,
> >>>       > which will be used by the timer library to synchronize init/finalize
> >>>       > calls among multiple processes.
> >>>       >
> >>>       > [1] http://patches.dpdk.org/patch/53334/
> >>>       >
> >>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>      <mailto:erik.g.carrillo@intel.com>>
> >>>       > ---
> >>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >>>       >  1 file changed, 4 insertions(+)
> >>>       >
> >>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
> >>>      b/doc/guides/rel_notes/deprecation.rst
> >>>       > index b47c8c2..7551383 100644
> >>>       > --- a/doc/guides/rel_notes/deprecation.rst
> >>>       > +++ b/doc/guides/rel_notes/deprecation.rst
> >>>       > @@ -31,6 +31,10 @@ Deprecation Notices
> >>>       >
> >>>       >      + ``rte_eal_devargs_type_count``
> >>>       >
> >>>       > +* eal: the ``rte_mem_config`` struct will change to include a
> >>>      new lock that
> >>>       > +  will allow the timer subsystem to safely release its
> >>>      allocations at cleanup
> >>>       > +  time. This will result in an ABI break.
> >>>       > +
> >>>       >  * 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.
> >>>
> >>>      NAK
> >>>
> >>>      Please go to the effort of making rte_mem_config not part of the
> >>>      visible ABI.
> >>>      Then change it.
> >>>
> >>>
> >>> +1.
> >>
> >> I agree on principle, however this won't solve the issue. It doesn't need to
> >> be externally visible, but that's not all of its problems - it's also shared
> >> between processes so there's an ABI contract between primary and secondary
> >> too. This means that, even if the structure itself is not public, any
> >> changes to it will still result in an ABI break. That's the nature of our
> >> shared memory.
> >>
> >> In other words, if your goal is to avoid ABI breaks on changing this
> >> structure, making it internal won't help in the slightest.
> >>
> > 
> > Is there an ABI contract between primary and secondary. I always assumed
> > that if using secondary processes the requirement (though undocumented) was
> > that both had to be linked against the exact same versions of DPDK?
> > 
> 
> The fact that it's undocumented means we can't assume everyone will do 
> that :)
> 
> If the community agrees that primary/secondary processes should always 
> use the same DPDK version (regardless of static/dynamic builds etc.), 
> then this problem would probably be solved.

+1 to document that primary/secondary with different DPDK versions
is not supported.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Ray Kinsella]

On 09/05/2019 10:38, Thomas Monjalon wrote:
> 09/05/2019 11:37, Burakov, Anatoly:
>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>
>>>>>      On Wed,  8 May 2019 17:48:06 -0500
>>>>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>      <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>
>>>>>       > Due to an upcoming fix to allow the timer library to safely free its
>>>>>       > allocations during the finalize() call[1], an ABI change will be
>>>>>       > required. A new lock will be added to the rte_mem_config structure,
>>>>>       > which will be used by the timer library to synchronize init/finalize
>>>>>       > calls among multiple processes.
>>>>>       >
>>>>>       > [1] http://patches.dpdk.org/patch/53334/
>>>>>       >
>>>>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>      <mailto:erik.g.carrillo@intel.com>>
>>>>>       > ---
>>>>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>>>       >  1 file changed, 4 insertions(+)
>>>>>       >
>>>>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>      b/doc/guides/rel_notes/deprecation.rst
>>>>>       > index b47c8c2..7551383 100644
>>>>>       > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>       > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>       > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>       >
>>>>>       >      + ``rte_eal_devargs_type_count``
>>>>>       >
>>>>>       > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>      new lock that
>>>>>       > +  will allow the timer subsystem to safely release its
>>>>>      allocations at cleanup
>>>>>       > +  time. This will result in an ABI break.
>>>>>       > +
>>>>>       >  * 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.
>>>>>
>>>>>      NAK
>>>>>
>>>>>      Please go to the effort of making rte_mem_config not part of the
>>>>>      visible ABI.
>>>>>      Then change it.
>>>>>
>>>>>
>>>>> +1.
>>>>
>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>> be externally visible, but that's not all of its problems - it's also shared
>>>> between processes so there's an ABI contract between primary and secondary
>>>> too. This means that, even if the structure itself is not public, any
>>>> changes to it will still result in an ABI break. That's the nature of our
>>>> shared memory.
>>>>
>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>> structure, making it internal won't help in the slightest.
>>>>
>>>
>>> Is there an ABI contract between primary and secondary. I always assumed
>>> that if using secondary processes the requirement (though undocumented) was
>>> that both had to be linked against the exact same versions of DPDK?
>>>
>>
>> The fact that it's undocumented means we can't assume everyone will do 
>> that :)
>>
>> If the community agrees that primary/secondary processes should always 
>> use the same DPDK version (regardless of static/dynamic builds etc.), 
>> then this problem would probably be solved.
> 
> +1 to document that primary/secondary with different DPDK versions
> is not supported.
> 

+1,

but I think we need to go farther - we need a secondary process to check
with the primary process.
We can't assume everyone will read the documentation.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Ray Kinsella]

On 09/05/2019 10:38, Thomas Monjalon wrote:
> 09/05/2019 11:37, Burakov, Anatoly:
>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>
>>>>>      On Wed,  8 May 2019 17:48:06 -0500
>>>>>      Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>      <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>
>>>>>       > Due to an upcoming fix to allow the timer library to safely free its
>>>>>       > allocations during the finalize() call[1], an ABI change will be
>>>>>       > required. A new lock will be added to the rte_mem_config structure,
>>>>>       > which will be used by the timer library to synchronize init/finalize
>>>>>       > calls among multiple processes.
>>>>>       >
>>>>>       > [1] http://patches.dpdk.org/patch/53334/
>>>>>       >
>>>>>       > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>      <mailto:erik.g.carrillo@intel.com>>
>>>>>       > ---
>>>>>       >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>>>       >  1 file changed, 4 insertions(+)
>>>>>       >
>>>>>       > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>      b/doc/guides/rel_notes/deprecation.rst
>>>>>       > index b47c8c2..7551383 100644
>>>>>       > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>       > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>       > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>       >
>>>>>       >      + ``rte_eal_devargs_type_count``
>>>>>       >
>>>>>       > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>      new lock that
>>>>>       > +  will allow the timer subsystem to safely release its
>>>>>      allocations at cleanup
>>>>>       > +  time. This will result in an ABI break.
>>>>>       > +
>>>>>       >  * 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.
>>>>>
>>>>>      NAK
>>>>>
>>>>>      Please go to the effort of making rte_mem_config not part of the
>>>>>      visible ABI.
>>>>>      Then change it.
>>>>>
>>>>>
>>>>> +1.
>>>>
>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>> be externally visible, but that's not all of its problems - it's also shared
>>>> between processes so there's an ABI contract between primary and secondary
>>>> too. This means that, even if the structure itself is not public, any
>>>> changes to it will still result in an ABI break. That's the nature of our
>>>> shared memory.
>>>>
>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>> structure, making it internal won't help in the slightest.
>>>>
>>>
>>> Is there an ABI contract between primary and secondary. I always assumed
>>> that if using secondary processes the requirement (though undocumented) was
>>> that both had to be linked against the exact same versions of DPDK?
>>>
>>
>> The fact that it's undocumented means we can't assume everyone will do 
>> that :)
>>
>> If the community agrees that primary/secondary processes should always 
>> use the same DPDK version (regardless of static/dynamic builds etc.), 
>> then this problem would probably be solved.
> 
> +1 to document that primary/secondary with different DPDK versions
> is not supported.
> 

+1,

but I think we need to go farther - we need a secondary process to check
with the primary process.
We can't assume everyone will read the documentation.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 10:50 AM, Ray Kinsella wrote:
> 
> 
> On 09/05/2019 10:38, Thomas Monjalon wrote:
>> 09/05/2019 11:37, Burakov, Anatoly:
>>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>>
>>>>>>       On Wed,  8 May 2019 17:48:06 -0500
>>>>>>       Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>>       <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>>
>>>>>>        > Due to an upcoming fix to allow the timer library to safely free its
>>>>>>        > allocations during the finalize() call[1], an ABI change will be
>>>>>>        > required. A new lock will be added to the rte_mem_config structure,
>>>>>>        > which will be used by the timer library to synchronize init/finalize
>>>>>>        > calls among multiple processes.
>>>>>>        >
>>>>>>        > [1] http://patches.dpdk.org/patch/53334/
>>>>>>        >
>>>>>>        > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>>       <mailto:erik.g.carrillo@intel.com>>
>>>>>>        > ---
>>>>>>        >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>>>>        >  1 file changed, 4 insertions(+)
>>>>>>        >
>>>>>>        > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>       b/doc/guides/rel_notes/deprecation.rst
>>>>>>        > index b47c8c2..7551383 100644
>>>>>>        > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>        > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>        > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>>        >
>>>>>>        >      + ``rte_eal_devargs_type_count``
>>>>>>        >
>>>>>>        > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>>       new lock that
>>>>>>        > +  will allow the timer subsystem to safely release its
>>>>>>       allocations at cleanup
>>>>>>        > +  time. This will result in an ABI break.
>>>>>>        > +
>>>>>>        >  * 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.
>>>>>>
>>>>>>       NAK
>>>>>>
>>>>>>       Please go to the effort of making rte_mem_config not part of the
>>>>>>       visible ABI.
>>>>>>       Then change it.
>>>>>>
>>>>>>
>>>>>> +1.
>>>>>
>>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>>> be externally visible, but that's not all of its problems - it's also shared
>>>>> between processes so there's an ABI contract between primary and secondary
>>>>> too. This means that, even if the structure itself is not public, any
>>>>> changes to it will still result in an ABI break. That's the nature of our
>>>>> shared memory.
>>>>>
>>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>>> structure, making it internal won't help in the slightest.
>>>>>
>>>>
>>>> Is there an ABI contract between primary and secondary. I always assumed
>>>> that if using secondary processes the requirement (though undocumented) was
>>>> that both had to be linked against the exact same versions of DPDK?
>>>>
>>>
>>> The fact that it's undocumented means we can't assume everyone will do
>>> that :)
>>>
>>> If the community agrees that primary/secondary processes should always
>>> use the same DPDK version (regardless of static/dynamic builds etc.),
>>> then this problem would probably be solved.
>>
>> +1 to document that primary/secondary with different DPDK versions
>> is not supported.
>>
> 
> +1,
> 
> but I think we need to go farther - we need a secondary process to check
> with the primary process.
> We can't assume everyone will read the documentation.
> 

That easily can be done, yes.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 09-May-19 10:50 AM, Ray Kinsella wrote:
> 
> 
> On 09/05/2019 10:38, Thomas Monjalon wrote:
>> 09/05/2019 11:37, Burakov, Anatoly:
>>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>>
>>>>>>       On Wed,  8 May 2019 17:48:06 -0500
>>>>>>       Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>>       <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>>
>>>>>>        > Due to an upcoming fix to allow the timer library to safely free its
>>>>>>        > allocations during the finalize() call[1], an ABI change will be
>>>>>>        > required. A new lock will be added to the rte_mem_config structure,
>>>>>>        > which will be used by the timer library to synchronize init/finalize
>>>>>>        > calls among multiple processes.
>>>>>>        >
>>>>>>        > [1] http://patches.dpdk.org/patch/53334/
>>>>>>        >
>>>>>>        > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>>       <mailto:erik.g.carrillo@intel.com>>
>>>>>>        > ---
>>>>>>        >  doc/guides/rel_notes/deprecation.rst | 4 ++++
>>>>>>        >  1 file changed, 4 insertions(+)
>>>>>>        >
>>>>>>        > diff --git a/doc/guides/rel_notes/deprecation.rst
>>>>>>       b/doc/guides/rel_notes/deprecation.rst
>>>>>>        > index b47c8c2..7551383 100644
>>>>>>        > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>>        > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>>        > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>>        >
>>>>>>        >      + ``rte_eal_devargs_type_count``
>>>>>>        >
>>>>>>        > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>>       new lock that
>>>>>>        > +  will allow the timer subsystem to safely release its
>>>>>>       allocations at cleanup
>>>>>>        > +  time. This will result in an ABI break.
>>>>>>        > +
>>>>>>        >  * 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.
>>>>>>
>>>>>>       NAK
>>>>>>
>>>>>>       Please go to the effort of making rte_mem_config not part of the
>>>>>>       visible ABI.
>>>>>>       Then change it.
>>>>>>
>>>>>>
>>>>>> +1.
>>>>>
>>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>>> be externally visible, but that's not all of its problems - it's also shared
>>>>> between processes so there's an ABI contract between primary and secondary
>>>>> too. This means that, even if the structure itself is not public, any
>>>>> changes to it will still result in an ABI break. That's the nature of our
>>>>> shared memory.
>>>>>
>>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>>> structure, making it internal won't help in the slightest.
>>>>>
>>>>
>>>> Is there an ABI contract between primary and secondary. I always assumed
>>>> that if using secondary processes the requirement (though undocumented) was
>>>> that both had to be linked against the exact same versions of DPDK?
>>>>
>>>
>>> The fact that it's undocumented means we can't assume everyone will do
>>> that :)
>>>
>>> If the community agrees that primary/secondary processes should always
>>> use the same DPDK version (regardless of static/dynamic builds etc.),
>>> then this problem would probably be solved.
>>
>> +1 to document that primary/secondary with different DPDK versions
>> is not supported.
>>
> 
> +1,
> 
> but I think we need to go farther - we need a secondary process to check
> with the primary process.
> We can't assume everyone will read the documentation.
> 

That easily can be done, yes.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.  
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>  
> > 
> > +1,
> > 
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >   
> 
> That easily can be done, yes.

Agree with the consensus that primary/secondary must be on the same version.
Think even driver internal data structures have to be compatiable.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.  
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>  
> > 
> > +1,
> > 
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >   
> 
> That easily can be done, yes.

Agree with the consensus that primary/secondary must be on the same version.
Think even driver internal data structures have to be compatiable.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> On 09-May-19 10:50 AM, Ray Kinsella wrote:
> > 
> > 
> > On 09/05/2019 10:38, Thomas Monjalon wrote:  
> >> 09/05/2019 11:37, Burakov, Anatoly:  
> >>> On 09-May-19 10:06 AM, Bruce Richardson wrote:  
> >>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:  
> >>>>> On 09-May-19 8:05 AM, David Marchand wrote:  
> >>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>>>>
> >>>>>>       On Wed,  8 May 2019 17:48:06 -0500
> >>>>>>       Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>>>>       <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>>>>  
> >>>>>>        > Due to an upcoming fix to allow the timer library to safely free its
> >>>>>>        > allocations during the finalize() call[1], an ABI change will be
> >>>>>>        > required. A new lock will be added to the rte_mem_config structure,
> >>>>>>        > which will be used by the timer library to synchronize init/finalize
> >>>>>>        > calls among multiple processes.
> >>>>>>        >
> >>>>>>        > [1] http://patches.dpdk.org/patch/53334/
> >>>>>>        >
> >>>>>>        > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com  
> >>>>>>       <mailto:erik.g.carrillo@intel.com>>  
> >>>>>>        > ---
> >>>>>>        >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >>>>>>        >  1 file changed, 4 insertions(+)
> >>>>>>        >
> >>>>>>        > diff --git a/doc/guides/rel_notes/deprecation.rst  
> >>>>>>       b/doc/guides/rel_notes/deprecation.rst  
> >>>>>>        > index b47c8c2..7551383 100644
> >>>>>>        > --- a/doc/guides/rel_notes/deprecation.rst
> >>>>>>        > +++ b/doc/guides/rel_notes/deprecation.rst
> >>>>>>        > @@ -31,6 +31,10 @@ Deprecation Notices
> >>>>>>        >
> >>>>>>        >      + ``rte_eal_devargs_type_count``
> >>>>>>        >
> >>>>>>        > +* eal: the ``rte_mem_config`` struct will change to include a  
> >>>>>>       new lock that  
> >>>>>>        > +  will allow the timer subsystem to safely release its  
> >>>>>>       allocations at cleanup  
> >>>>>>        > +  time. This will result in an ABI break.
> >>>>>>        > +
> >>>>>>        >  * 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.  
> >>>>>>
> >>>>>>       NAK
> >>>>>>
> >>>>>>       Please go to the effort of making rte_mem_config not part of the
> >>>>>>       visible ABI.
> >>>>>>       Then change it.
> >>>>>>
> >>>>>>
> >>>>>> +1.  
> >>>>>
> >>>>> I agree on principle, however this won't solve the issue. It doesn't need to
> >>>>> be externally visible, but that's not all of its problems - it's also shared
> >>>>> between processes so there's an ABI contract between primary and secondary
> >>>>> too. This means that, even if the structure itself is not public, any
> >>>>> changes to it will still result in an ABI break. That's the nature of our
> >>>>> shared memory.
> >>>>>
> >>>>> In other words, if your goal is to avoid ABI breaks on changing this
> >>>>> structure, making it internal won't help in the slightest.
> >>>>>  
> >>>>
> >>>> Is there an ABI contract between primary and secondary. I always assumed
> >>>> that if using secondary processes the requirement (though undocumented) was
> >>>> that both had to be linked against the exact same versions of DPDK?
> >>>>  
> >>>
> >>> The fact that it's undocumented means we can't assume everyone will do
> >>> that :)
> >>>
> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.  
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>  
> > 
> > +1,
> > 
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >   
> 
> That easily can be done, yes.
> 

FYI - I submitted patches to make lcore_config private.
These patches should handle mem_config.
And I started on making eal_config private (but mem_config got in the way).

Other candidates are the internals behind ethdev and devices.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Stephen Hemminger]

On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:

> On 09-May-19 10:50 AM, Ray Kinsella wrote:
> > 
> > 
> > On 09/05/2019 10:38, Thomas Monjalon wrote:  
> >> 09/05/2019 11:37, Burakov, Anatoly:  
> >>> On 09-May-19 10:06 AM, Bruce Richardson wrote:  
> >>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:  
> >>>>> On 09-May-19 8:05 AM, David Marchand wrote:  
> >>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>>>>
> >>>>>>       On Wed,  8 May 2019 17:48:06 -0500
> >>>>>>       Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>>>>       <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>>>>  
> >>>>>>        > Due to an upcoming fix to allow the timer library to safely free its
> >>>>>>        > allocations during the finalize() call[1], an ABI change will be
> >>>>>>        > required. A new lock will be added to the rte_mem_config structure,
> >>>>>>        > which will be used by the timer library to synchronize init/finalize
> >>>>>>        > calls among multiple processes.
> >>>>>>        >
> >>>>>>        > [1] http://patches.dpdk.org/patch/53334/
> >>>>>>        >
> >>>>>>        > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com  
> >>>>>>       <mailto:erik.g.carrillo@intel.com>>  
> >>>>>>        > ---
> >>>>>>        >  doc/guides/rel_notes/deprecation.rst | 4 ++++
> >>>>>>        >  1 file changed, 4 insertions(+)
> >>>>>>        >
> >>>>>>        > diff --git a/doc/guides/rel_notes/deprecation.rst  
> >>>>>>       b/doc/guides/rel_notes/deprecation.rst  
> >>>>>>        > index b47c8c2..7551383 100644
> >>>>>>        > --- a/doc/guides/rel_notes/deprecation.rst
> >>>>>>        > +++ b/doc/guides/rel_notes/deprecation.rst
> >>>>>>        > @@ -31,6 +31,10 @@ Deprecation Notices
> >>>>>>        >
> >>>>>>        >      + ``rte_eal_devargs_type_count``
> >>>>>>        >
> >>>>>>        > +* eal: the ``rte_mem_config`` struct will change to include a  
> >>>>>>       new lock that  
> >>>>>>        > +  will allow the timer subsystem to safely release its  
> >>>>>>       allocations at cleanup  
> >>>>>>        > +  time. This will result in an ABI break.
> >>>>>>        > +
> >>>>>>        >  * 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.  
> >>>>>>
> >>>>>>       NAK
> >>>>>>
> >>>>>>       Please go to the effort of making rte_mem_config not part of the
> >>>>>>       visible ABI.
> >>>>>>       Then change it.
> >>>>>>
> >>>>>>
> >>>>>> +1.  
> >>>>>
> >>>>> I agree on principle, however this won't solve the issue. It doesn't need to
> >>>>> be externally visible, but that's not all of its problems - it's also shared
> >>>>> between processes so there's an ABI contract between primary and secondary
> >>>>> too. This means that, even if the structure itself is not public, any
> >>>>> changes to it will still result in an ABI break. That's the nature of our
> >>>>> shared memory.
> >>>>>
> >>>>> In other words, if your goal is to avoid ABI breaks on changing this
> >>>>> structure, making it internal won't help in the slightest.
> >>>>>  
> >>>>
> >>>> Is there an ABI contract between primary and secondary. I always assumed
> >>>> that if using secondary processes the requirement (though undocumented) was
> >>>> that both had to be linked against the exact same versions of DPDK?
> >>>>  
> >>>
> >>> The fact that it's undocumented means we can't assume everyone will do
> >>> that :)
> >>>
> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.  
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>  
> > 
> > +1,
> > 
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >   
> 
> That easily can be done, yes.
> 

FYI - I submitted patches to make lcore_config private.
These patches should handle mem_config.
And I started on making eal_config private (but mem_config got in the way).

Other candidates are the internals behind ethdev and devices.

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 08-May-19 11:48 PM, Erik Gabriel Carrillo wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
> 
> [1] http://patches.dpdk.org/patch/53334/
> 
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---

As per discussion, please change the deprecation notice to instead make 
rte_eal_memconfig private.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup

[Burakov, Anatoly]

On 08-May-19 11:48 PM, Erik Gabriel Carrillo wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
> 
> [1] http://patches.dpdk.org/patch/53334/
> 
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---

As per discussion, please change the deprecation notice to instead make 
rte_eal_memconfig private.

-- 
Thanks,
Anatoly

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

[Erik Gabriel Carrillo]

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

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

[Erik Gabriel Carrillo]

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

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

[Burakov, Anatoly]

On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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.
> 

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly

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

[Burakov, Anatoly]

On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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.
> 

Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

-- 
Thanks,
Anatoly

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

[Bruce Richardson]

On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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.
> > 
> 
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> 
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

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

[Bruce Richardson]

On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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.
> > 
> 
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> 
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

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

[Thomas Monjalon]

10/05/2019 11:34, Bruce Richardson:
> On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> > On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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)
> > > 
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > +* 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.
> > 
> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>

Applied, thanks

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

[Thomas Monjalon]

10/05/2019 11:34, Bruce Richardson:
> On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> > On 09-May-19 7:51 PM, Erik Gabriel Carrillo 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)
> > > 
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > +* 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.
> > 
> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>

Applied, thanks

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

[David Marchand]

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

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

[David Marchand]

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