> > >> You can have arm, arm64, mips64, etc. directories inside > > >> examples/ipfrag. > > > > > > This does not scale in practice. If another example comes along, does > > > that also need to split whatever is determined to be "arch" code into > > > "arch" directories within its own folder? > > > > > > I recommend that this contribution be accepted without any further > > change. > > > > From my perspective, separate arm, aarch64 and generic headers would be > > sufficient, even if they are not put under separate directories. That > > was just a suggestion. > > > > The main concern I have with this is that: ODP examples should demonstrate how > ODP APIs are used to do X. In other words: "If you implement X like this with > ODP APIs, your code is: > > * 100% portable > * still good performance > * clean and easy to understand / maintain" > > Super optimized, architecture specific implementation of X would not drive > that > purpose. It also leads to maintenance issues later on - a bug found and fixed > on CPU arch Y does not get automatically fixed for arch Z. > > We are drawing a line here if embedded assembly or otherwise arch dependent > code belongs to example applications. I'd say it does not, since HW > abstraction is the sole purpose of ODP.
You know far more about ODP than I, so please correct me if I'm wrong here, but my understanding is that ODP is primarily about abstracting hardware **accelerators** (in a networking context). It does not, and should not, be overly involved with the details of how programmers may wish to write and abstract other parts of their programs. This example should run perfectly well on a wide range of CPUs — that is, pretty much anything with 32 bit or 64 bit pointers and that has a compiler supporting GCC's "__atomic_compare_exchange_n" for double the pointer size — and consists of code that is almost entirely independent of other architectural details. There is a single exception to this, in that the standard 128-bit "__atomic_compare_exchange_n" implementation on ARM is not lock-free, and so there are some short snippets of inline assembly, confined to a single file (in the new version of the patch I have locally), that resolve this. I don't see a problem here.
