doc: announce modification in eventdev structure

  From: Akhil Goyal <gakhil@marvell.com>

A new field ``ca_enqueue`` is added in ``rte_eventdev``
in the end to maintain ABI. It needs to be moved above
in the structure to align with other enqueue callbacks.

Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)
  

On Thu, Apr 15, 2021 at 2:39 PM <gakhil@marvell.com> wrote:
>
> From: Akhil Goyal <gakhil@marvell.com>
>
> A new field ``ca_enqueue`` is added in ``rte_eventdev``
> in the end to maintain ABI. It needs to be moved above
> in the structure to align with other enqueue callbacks.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>


Acked-by: Jerin Jacob <jerinj@marvell.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 2afc84c39..a973de4a9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -127,6 +127,10 @@ Deprecation Notices
>    values to the function ``rte_event_eth_rx_adapter_queue_add`` using
>    the structure ``rte_event_eth_rx_adapter_queue_add``.
>
> +* eventdev: The function pointer ``ca_enqueue`` in structure ``rte_eventdev``
> +  will be moved after ``txa_enqueue`` so that all enqueue/dequeue
> +  function pointers are adjacent to each other.
> +
>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
>    traffic classes, and subport level configuration of pipes and queues
>    changes will be made to macros, data structures and API functions defined
> --
> 2.25.1
>
  

On 15/04/2021 10:08, gakhil@marvell.com wrote:
> From: Akhil Goyal <gakhil@marvell.com>
> 
> A new field ``ca_enqueue`` is added in ``rte_eventdev``
> in the end to maintain ABI. It needs to be moved above
> in the structure to align with other enqueue callbacks.
> 
> Signed-off-by: Akhil Goyal <gakhil@marvell.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 2afc84c39..a973de4a9 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -127,6 +127,10 @@ Deprecation Notices
>    values to the function ``rte_event_eth_rx_adapter_queue_add`` using
>    the structure ``rte_event_eth_rx_adapter_queue_add``.
>  
> +* eventdev: The function pointer ``ca_enqueue`` in structure ``rte_eventdev``
> +  will be moved after ``txa_enqueue`` so that all enqueue/dequeue
> +  function pointers are adjacent to each other.
> +
>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
>    traffic classes, and subport level configuration of pipes and queues
>    changes will be made to macros, data structures and API functions defined
> 

I admire the disipline - but since you are not actually removing ca_enqueue,
just moving it in memory when the new ABI is declared in anycase, this is not required.

Thanks,

Ray K
  

Hi Ray,
> > @@ -127,6 +127,10 @@ Deprecation Notices
> >    values to the function ``rte_event_eth_rx_adapter_queue_add`` using
> >    the structure ``rte_event_eth_rx_adapter_queue_add``.
> >
> > +* eventdev: The function pointer ``ca_enqueue`` in structure
> ``rte_eventdev``
> > +  will be moved after ``txa_enqueue`` so that all enqueue/dequeue
> > +  function pointers are adjacent to each other.
> > +
> >  * sched: To allow more traffic classes, flexible mapping of pipe queues to
> >    traffic classes, and subport level configuration of pipes and queues
> >    changes will be made to macros, data structures and API functions
> defined
> >
> 
> I admire the disipline - but since you are not actually removing ca_enqueue,
> just moving it in memory when the new ABI is declared in anycase, this is not
> required.
> 

Does it mean we can move elements in a structure without giving deprecation notice?

-akhil
  

On 03/05/2021 12:18, Akhil Goyal wrote:
> Hi Ray,
>>> @@ -127,6 +127,10 @@ Deprecation Notices
>>>    values to the function ``rte_event_eth_rx_adapter_queue_add`` using
>>>    the structure ``rte_event_eth_rx_adapter_queue_add``.
>>>
>>> +* eventdev: The function pointer ``ca_enqueue`` in structure
>> ``rte_eventdev``
>>> +  will be moved after ``txa_enqueue`` so that all enqueue/dequeue
>>> +  function pointers are adjacent to each other.
>>> +
>>>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
>>>    traffic classes, and subport level configuration of pipes and queues
>>>    changes will be made to macros, data structures and API functions
>> defined
>>>
>>
>> I admire the disipline - but since you are not actually removing ca_enqueue,
>> just moving it in memory when the new ABI is declared in anycase, this is not
>> required.
>>
> 
> Does it mean we can move elements in a structure without giving deprecation notice?
> 

well if memory serves - you aren't depreciating the field, just moving it, right?
And you are aligning the change with an ABI break in anycase - so I think it is all good.

Ray K
  

On Tue, May 4, 2021 at 3:06 PM Kinsella, Ray <mdr@ashroe.eu> wrote:
>
>
>
> On 03/05/2021 12:18, Akhil Goyal wrote:
> > Hi Ray,
> >>> @@ -127,6 +127,10 @@ Deprecation Notices
> >>>    values to the function ``rte_event_eth_rx_adapter_queue_add`` using
> >>>    the structure ``rte_event_eth_rx_adapter_queue_add``.
> >>>
> >>> +* eventdev: The function pointer ``ca_enqueue`` in structure
> >> ``rte_eventdev``
> >>> +  will be moved after ``txa_enqueue`` so that all enqueue/dequeue
> >>> +  function pointers are adjacent to each other.
> >>> +
> >>>  * sched: To allow more traffic classes, flexible mapping of pipe queues to
> >>>    traffic classes, and subport level configuration of pipes and queues
> >>>    changes will be made to macros, data structures and API functions
> >> defined
> >>>
> >>
> >> I admire the disipline - but since you are not actually removing ca_enqueue,
> >> just moving it in memory when the new ABI is declared in anycase, this is not
> >> required.
> >>
> >
> > Does it mean we can move elements in a structure without giving deprecation notice?
> >
>
> well if memory serves - you aren't depreciating the field, just moving it, right?
> And you are aligning the change with an ABI break in anycase - so I think it is all good.

OK. Change the status of the patch in patchwork as "Not applicable"


>
> Ray K