> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] > Sent: Friday, 17 May 2024 06.27 > > + Bruce for feedback on x86 architecture > > > On May 16, 2024, at 10:30 PM, Stephen Hemminger <step...@networkplumber.org> > wrote: > > > > On Fri, 17 May 2024 02:45:12 +0000 > > Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> wrote: > > > >>> + * A counter is 64 bit value that is safe from split read/write > >>> + * on 32 bit platforms. It assumes that only one cpu at a time > >> If we are defining the counter in this manner, then implementation cannot > be generic. I think architectures will have constraints if they have to ensure > the 64b variables are not split. > >> > >> I think we at least need the counter to be aligned on 8B boundary to have > generic code. > > > > The C standard has always guaranteed that read and write to unsigned log > will not be split. > As I understand, this is true only if the variable is an atomic variable. If > not, there is no difference between atomic variables and non-atomic variables. > > > Therefore if arch is 64 bit native there is no need for atomics > At least on ARM architecture, if the variable is not aligned on 8B boundary, > the load or store are not atomic. I am sure it is the same on other > architectures.
I guess it depends on the architecture's natural alignment size and the compiler - especially on 32 bit architectures, where the natural alignment size is 4 bytes. We could play it safe and add alignment to the counter type: #include <stdalign.h> #ifdef RTE_ARCH_64 #if alignof(uint64_t) < sizeof(uint64_t) typedef alignas(8) uint64_t rte_counter64_t; #else typedef uint64_t rte_counter64_t; #endif #else #if alignof(RTE_ATOMIC(uint64_t)) < sizeof(uint64_t) typedef alignas(8) RTE_ATOMIC(uint64_t) rte_counter64_t; #else typedef RTE_ATOMIC(uint64_t) rte_counter64_t; #endif #endif This above is intentionally verbose, because some 32 bit architectures can implement 64 bit non-tearing counters without atomics [1], and the new 64 bit counter library should be prepared for accepting such optimizations. [1]: https://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35e9f...@smartserver.smartshare.dk/ Picking up on another branch of this discussion: This 64 bit counter library is *not* an internal API. Applications should use it for their counters too. > Bruce, any comments for x86?
