> > > 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.
I agree with Maxim. While it's perfectly possible for this patch to be modified such that it doesn't contain any ARM-specific code, I think the patch is more useful with this code. It better demonstrates what you might want to do on a real system, which frankly is what this example is all about. If you wanted a simple implementation of IPv4 reassembly, you definitely would not want to use the algorithm presented in this patch. This code is complicated exactly because it demonstrates an efficient, scalable approach that you might want to use in a real world application. And as such, I think the "proper" accompanying CAS implementations for ARM are warranted.
