[dpdk-dev] [PATCH v4 2/5] eal: add lcore accessors

[Bruce Richardson]

On Thu, May 30, 2019 at 07:00:36PM +0200, David Marchand wrote:
>    On Thu, May 30, 2019 at 3:39 PM Thomas Monjalon
>    <[1]thomas at monjalon.net> wrote:
> 
>      30/05/2019 12:11, Bruce Richardson:
>      > On Thu, May 30, 2019 at 09:40:08AM +0200, Thomas Monjalon wrote:
>      > > 30/05/2019 09:31, David Marchand:
>      > > > On Thu, May 30, 2019 at 12:51 AM Stephen Hemminger <
>      > > > [2]stephen at networkplumber.org> wrote:
>      > > >
>      > > > > On Thu, 30 May 2019 00:46:30 +0200
>      > > > > Thomas Monjalon <[3]thomas at monjalon.net> wrote:
>      > > > >
>      > > > > > 23/05/2019 15:58, David Marchand:
>      > > > > > > From: Stephen Hemminger <[4]stephen at networkplumber.org>
>      > > > > > >
>      > > > > > > The fields of the internal EAL core configuration are
>      currently
>      > > > > > > laid bare as part of the API. This is not good practice
>      and limits
>      > > > > > > fixing issues with layout and sizes.
>      > > > > > >
>      > > > > > > Make new accessor functions for the fields used by
>      current drivers
>      > > > > > > and examples.
>      > > > > > [...]
>      > > > > > > +DPDK_19.08 {
>      > > > > > > +   global:
>      > > > > > > +
>      > > > > > > +   rte_lcore_cpuset;
>      > > > > > > +   rte_lcore_index;
>      > > > > > > +   rte_lcore_to_cpu_id;
>      > > > > > > +   rte_lcore_to_socket_id;
>      > > > > > > +
>      > > > > > > +} DPDK_19.05;
>      > > > > > > +
>      > > > > > >  EXPERIMENTAL {
>      > > > > > >     global:
>      > > > > >
>      > > > > > Just to make sure, are we OK to introduce these functions
>      > > > > > as non-experimental?
>      > > > >
>      > > > > They were in previous releases as inlines this patch
>      converts them
>      > > > > to real functions.
>      > > > >
>      > > > >
>      > > > Well, yes and no.
>      > > >
>      > > > rte_lcore_index and rte_lcore_to_socket_id already existed, so
>      making them
>      > > > part of the ABI is fine for me.
>      > > >
>      > > > rte_lcore_to_cpu_id is new but seems quite safe in how it can
>      be used,
>      > > > adding it to the ABI is ok for me.
>      > >
>      > > It is used by DPAA and some test.
>      > > I guess adding as experimental is fine too?
>      > > I'm fine with both options, I'm just trying to apply the policy
>      > > we agreed on. Does this case deserve an exception?
>      > >
>      >
>      > While it may be a good candidate, I'm not sure how much making an
>      exception
>      > for it really matters. I'd be tempted to just mark it experimental
>      and then
>      > have it stable for the 19.11 release. What do we really lose by
>      waiting a
>      > release to stabilize it?
>      I would agree Bruce.
>      If no more comment, I will wait for a v5 of this series.
> 
>    I agree that there is no reason we make an exception for those 2 new
>    ones.
>    But to me the existing rte_lcore_index and rte_lcore_to_socket_id must
>    be marked as stable.
>    This is to avoid breaking existing users that did not set
>    ALLOW_EXPERIMENTAL_API.
>    I will prepare a v5 later.
>    --
Yes, agreed. Any existing APIs that were already present as static inlines
can go straight to stable when added to the .map file.

/Bruce