eal: make rte_lcore_cpuset and rte_lcore_to_cpu_id stable

  These were converted from inline to functions in 19.11
and should be marked as stable now.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 lib/eal/include/rte_lcore.h | 8 --------
 lib/eal/version.map         | 4 ++--
 2 files changed, 2 insertions(+), 10 deletions(-)
  

On 8/31/21 11:08 PM, Stephen Hemminger wrote:
> These were converted from inline to functions in 19.11
> and should be marked as stable now.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  lib/eal/include/rte_lcore.h | 8 --------
>  lib/eal/version.map         | 4 ++--
>  2 files changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> index 1550b75da0a5..cf6203a9af79 100644
> --- a/lib/eal/include/rte_lcore.h
> +++ b/lib/eal/include/rte_lcore.h
> @@ -172,9 +172,6 @@ unsigned int
>  rte_lcore_to_socket_id(unsigned int lcore_id);
>  
>  /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change without prior notice.
> - *
>   * Return the id of the lcore on a socket starting from zero.
>   *
>   * @param lcore_id
> @@ -182,23 +179,18 @@ rte_lcore_to_socket_id(unsigned int lcore_id);
>   * @return
>   *   The relative index, or -1 if not enabled.
>   */
> -__rte_experimental
>  int
>  rte_lcore_to_cpu_id(int lcore_id);
>  
>  #ifdef RTE_HAS_CPUSET
>  
>  /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change without prior notice.
> - *
>   * Return the cpuset for a given lcore.
>   * @param lcore_id
>   *   the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
>   * @return
>   *   The cpuset of that lcore
>   */
> -__rte_experimental
>  rte_cpuset_t
>  rte_lcore_cpuset(unsigned int lcore_id);

I'm wondering why negative lcore_id is supported above
with special meaning, but not supported here.

>  
> diff --git a/lib/eal/version.map b/lib/eal/version.map
> index beeb986adcaf..14565aa10df4 100644
> --- a/lib/eal/version.map
> +++ b/lib/eal/version.map
> @@ -98,9 +98,11 @@ DPDK_22 {
>  	rte_keepalive_register_core; # WINDOWS_NO_EXPORT
>  	rte_keepalive_register_relay_callback; # WINDOWS_NO_EXPORT
>  	rte_lcore_count;
> +	rte_lcore_cpuset;
>  	rte_lcore_has_role;
>  	rte_lcore_index;
>  	rte_lcore_is_enabled;
> +	rte_lcore_to_cpu_id;
>  	rte_lcore_to_socket_id;
>  	rte_log;
>  	rte_log_cur_msg_loglevel;
> @@ -322,8 +324,6 @@ EXPERIMENTAL {
>  
>  	# added in 19.08
>  	rte_intr_ack;
> -	rte_lcore_cpuset;
> -	rte_lcore_to_cpu_id;
>  	rte_mcfg_timer_lock;
>  	rte_mcfg_timer_unlock;
>  	rte_rand_max; # WINDOWS_NO_EXPORT
>
  

> >  /**
> > - * @warning
> > - * @b EXPERIMENTAL: this API may change without prior notice.
> > - *
> >   * Return the cpuset for a given lcore.
> >   * @param lcore_id
> >   *   the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
> >   * @return
> >   *   The cpuset of that lcore
> >   */
> > -__rte_experimental
> >  rte_cpuset_t
> >  rte_lcore_cpuset(unsigned int lcore_id);  
> 
> I'm wondering why negative lcore_id is supported above
> with special meaning, but not supported here.

The DPDK API stability in this case means staying bug-for-bug
compatible. I.e passing -1 as unsigned int results in UINT_MAX which
is invalid.
  

On 9/1/21 8:16 PM, Stephen Hemminger wrote:
> 
>>>  /**
>>> - * @warning
>>> - * @b EXPERIMENTAL: this API may change without prior notice.
>>> - *
>>>   * Return the cpuset for a given lcore.
>>>   * @param lcore_id
>>>   *   the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
>>>   * @return
>>>   *   The cpuset of that lcore
>>>   */
>>> -__rte_experimental
>>>  rte_cpuset_t
>>>  rte_lcore_cpuset(unsigned int lcore_id);  
>>
>> I'm wondering why negative lcore_id is supported above
>> with special meaning, but not supported here.
> 
> The DPDK API stability in this case means staying bug-for-bug
> compatible. I.e passing -1 as unsigned int results in UINT_MAX which
> is invalid.

Isn't promotion to stable the last chance to review and
fix without much pain?
  

On Thu, 2 Sep 2021 09:01:58 +0300
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru> wrote:

> On 9/1/21 8:16 PM, Stephen Hemminger wrote:
> >   
> >>>  /**
> >>> - * @warning
> >>> - * @b EXPERIMENTAL: this API may change without prior notice.
> >>> - *
> >>>   * Return the cpuset for a given lcore.
> >>>   * @param lcore_id
> >>>   *   the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
> >>>   * @return
> >>>   *   The cpuset of that lcore
> >>>   */
> >>> -__rte_experimental
> >>>  rte_cpuset_t
> >>>  rte_lcore_cpuset(unsigned int lcore_id);    
> >>
> >> I'm wondering why negative lcore_id is supported above
> >> with special meaning, but not supported here.  
> > 
> > The DPDK API stability in this case means staying bug-for-bug
> > compatible. I.e passing -1 as unsigned int results in UINT_MAX which
> > is invalid.  
> 
> Isn't promotion to stable the last chance to review and
> fix without much pain?
> 

My opinion is that if you want to change the API (including
semantics), then the experimental clock would have to be reset.