On 13 April 2017 at 13:49, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolai...@nokia-bell-labs.com> wrote:
> > > ODP is about HW abstraction and CPU instructions are HW features. Of > > course, > > > applications are free to use other libs/APIs/GCC features, but should > > our > > > examples do that? > > > > I'm not sure I agree that ODP primarily exists to abstract > non-accelerator > > HW, as far as I'm concerned that's really the job of the language, other > > libraries, and at the end of the day the programmer. (Talk about biting > > off > > more than you can chew: abstracting all hardware in the system?!) > > But regardless... > > > CPU cycle count read may be an instruction. Time counter read may an > instruction. 128 bit atomic CAS may be an instruction. AES crypto may have > multiple instructions. Queue enqueue may be an instruction. Memory barrier > may be embedded into multiple instructions... > > An application that uses these instruction directly is not portable. An > application that uses those through ODP API is portable. > > > > > > > "There is a single exception to this, in that the standard 128-bit > > > "__atomic_compare_exchange_n" implementation on ARM is not lock-free > > ..." > > > > > > This is the point. How about the built-in implementation on other CPU > > > architectures: MIPS, PPC, Tilera, Kalray, ... etc ? Does the code build > > on > > > those. If it does build, does it have race conditions or dead locks due > > to a > > > slightly different synchronization scheme? > > > > A change of architecture shouldn't introduce any additional race > > conditions > > or deadlocks, no. If this were the case, then I agree that this example > > would > > be far too fragile to include. Any standards compliant implementation of > > "__atomic_compare_exchange_n" will work fine - including the default one > > used > > by ARM platforms. As the algorithm underlying this example is supposed to > > be > > lock-free, though, a proper lock-free compare exchange implementation is > > the > > icing on the cake, showing off the properties of the algorithm in full. > > > > > Does the *example* need to show of lock-freeness? Would be enough to just > show of how IP frag/reassembly is usually done on ODP? > > Could all assembly and ARM #ifdefs be removed if we simply don't claim the > code to be lock-free ? > > -Petri > > I vote for saying yes here. I.e. this example should show lock-freeness and best performance usage doing ip frag with ODP. We can say that some examples can be very simple and minimal. Other examples might be complex and effective. Idea for first one is to show how some code works and idea for second one is to provide some building block of complex thing which can be reused by application developers. And that is great help from ARM writing such efficient building bocks for us. Maxim.
