Thread (141 messages) 141 messages, 9 authors, 2024-02-17

Re: [dpdk-dev] [PATCH v6 1/6] lib/eal: implement the family of rte bit operation APIs

From: Honnappa Nagarahalli <hidden>
Date: 2020-01-07 00:42:11

<snip>
quoted
quoted
On Sat, 21 Dec 2019 16:07:23 +0000
Honnappa Nagarahalli [off-list ref] wrote:
quoted
Converting these into macros will help remove the size based
duplication of
quoted
quoted
APIs. I came up with the following macro:
quoted
#define RTE_GET_BIT(nr, var, ret, memorder) \ ({ \
    if (sizeof(var) == sizeof(uint32_t)) { \
        uint32_t mask1 = 1U << (nr)%32; \
        ret = __atomic_load_n(&var, (memorder)) & mask1;\
    } \
    else {\
        uint64_t mask2 = 1UL << (nr)%64;\
        ret = __atomic_load_n(&var, (memorder)) & mask2;\
    } \
})
Macros are more error prone. Especially because this is in exposed header
file
quoted
That's another question I have. Why do we need to have these APIs in a
public header file? These will add to the ABI burden as well. These APIs
should be in a common-but-not-public header file. I am also not sure how
helpful these APIs are for applications as these APIs seem to have considered
requirements only from the PMDs.

Why do we have to wrap every C atomic builtin? What value is there in that?
As long as we stick to requirements from PMD we do not need to worry about every atomic builtin. We seem to be making these APIs public, which requires us to keep these APIs generic considering possible future requirements.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help