Ping. This gives tools for app/implementation to check "what is implemented"/"what app needs". Which is better than nothing.
-Petri > -----Original Message----- > From: lng-odp [mailto:[email protected]] On Behalf Of > EXT Savolainen, Petri (Nokia - FI/Espoo) > Sent: Wednesday, October 28, 2015 10:55 AM > To: EXT Nicolas Morey-Chaisemartin; [email protected] > Subject: Re: [lng-odp] [API-NEXT PATCH] api: atomic: added > atomic_is_lock_free > > > > > -----Original Message----- > > From: EXT Nicolas Morey-Chaisemartin [mailto:[email protected]] > > Sent: Wednesday, October 28, 2015 10:41 AM > > To: Savolainen, Petri (Nokia - FI/Espoo); [email protected] > > Subject: Re: [lng-odp] [API-NEXT PATCH] api: atomic: added > > atomic_is_lock_free > > > > > > > > On 10/28/2015 09:30 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > > > > >> -----Original Message----- > > >> From: EXT Nicolas Morey-Chaisemartin [mailto:[email protected]] > > >> Sent: Wednesday, October 28, 2015 10:23 AM > > >> To: Savolainen, Petri (Nokia - FI/Espoo); Ivan Khoronzhuk; lng- > > >> [email protected] > > >> Subject: Re: [lng-odp] [API-NEXT PATCH] api: atomic: added > > >> atomic_is_lock_free > > >> > > >> > > >> > > >> On 10/28/2015 09:12 AM, Savolainen, Petri (Nokia - FI/Espoo) > wrote: > > >>>>> Nicolas, you could define a platform specific init struct that > gives > > >> user > > >>>> option to tell which u64 operations will be called. If user > tells that > > >>>> cas/min/max_u64 are not called, you can implement everything > lock- > > free. > > >> The > > >>>> same is in git log entry: > > >>>>> " >> The same > > >>>> Everything is possible. But as this is brand new and not some > legacy > > >> we're > > >>>> trying to get running, I'd rather see something natively in the > API, > > >> than > > >>>> implement something platform specific. > > >>>>>>> atomic operation enum could be used for platform init to > guide > > >>>>>>> lock vs. lock-free implementation (e.g. if cas_64 is never > > >>>>>>> called, inc_64 can be lock-free)." > > >>>>> -Petri > > >>> int odp_init_global(const odp_init_t *params, const > odp_platform_init_t > > >> *platform_params); > > >>> We have odp_platform_init_t defined for this purpose. If a > platform > > needs > > >> extra information at start up to optimize itself, user can pass > that > > info > > >> through this. Other option is to insert that to generic odp init > params, > > >> but is that common enough optimization problem? Typically a > platform > > either > > >> has 64 bit atomics (including CAS) or it has not. > > >>> As a platform specific optimization it would look like this (for > > >> example): > > >>> odp_platform_init_t *platform_params = NULL; > > >>> > > >>> #ifdef __KALRAY > > >>> odp_platform_init_t kalray_params; > > >>> kalray_params.atomic_u64_ops = (1 << ODP_ATOMIC_OP_INIT) | > > >>> (1 << ODP_ATOMIC_OP_LOAD) | > > >>> (1 << ODP_ATOMIC_OP_STORE) | > > >>> (1 << ODP_ATOMIC_OP_FETCH_ADD) | > > >>> (1 << ODP_ATOMIC_OP_ADD) | > > >>> (1 << ODP_ATOMIC_OP_FETCH_SUB) | > > >>> (1 << ODP_ATOMIC_OP_SUB); > > >>> > > >>> kalray_params.optimize_foo = 1; > > >>> kalray_params.dont_use_bar = 1; > > >>> > > >>> platform_params = &kalray_params; > > >>> #endif > > >>> > > >>> odp_init_global(general_params, platform_params); > > >>> > > >>> > > >>> This is performance optimization, it's functionally correct to > give > > NULL. > > >> From user point of view it's a matter of reading user manual and > setting > > a > > >> small number of extra init params once in the application start > up. You > > can > > >> do this today. General params definition need more discussion > about > > >> pros/cons (what is generally helpful information). > > >>> > > >>> -Petri > > >>> > > >>> > > >> This would work, but it would impact *all* atomics instead of just > the > > few > > >> ones that may need CAS / MIN / MAX. > > > In the example above, user has not defined CAS/MIN/MAX so you can > safely > > assume that those calls will be never called and you can implement > > add/sub/inc/dec/... with lock-free native instructions and maybe > through an > > error if user still calls e.g. cas_u64. > > > > > > -Petri > > > > > > > > > > > I agree. But in a complex application where you could have hundreds > of > > atomics with only simple inc/decr (ref counters, packet id, etc.) and > need > > 2 atomics to store min/max levels, you would have to enable those > MIN/MAX > > operations and decrease performances for all of the atomics. > > > > IMHO, it would make sense to either have per atomic settings > (although it'd > > probably cost some memory), or have a simple class of atomic > > (odp_atomic_counters_uXX_t ?) that support only the basic operations > a > > counter would need. > > > > Nicolas > > This API reflect what you can do with C11 or GCC __atomics. Pure > counter API has been talked already, and could be a bit different. > There would be a thread local copy of each counter and user would > control the frequency of updating those local counters to the shared > memory. This atomics API (by definition) update the shared copy every > time. I think we could explore the counter API first and then see if > there's a need for this atomic_counter feature. > > -Petri > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
