On 10/26/2023 3:50 AM, Chaoyong He wrote: >>> On 10/24/2023 3:28 AM, Chaoyong He wrote: >>>> This patch series aims to add the NFP vDPA PMD, we also grab the >>>> common logic into the `drivers/common/nfp` directory. >>>> >>>> --- >>>> v2: >>>> * Grab more logic into the `drivers/common/nfp` directory. >>>> * Delete some logic which should be when moving logic. >>>> --- >>>> >>>> Chaoyong He (25): >>>> drivers: introduce the NFP common library >>>> net/nfp: make VF PMD using of NFP common module >>>> net/nfp: rename common module name >>>> net/nfp: rename ctrl module name >>>> net/nfp: extract the cap data field >>>> net/nfp: extract the qcp data field >>>> net/nfp: extract the ctrl BAR data field >>>> net/nfp: extract the ctrl data field >>>> net/nfp: change the parameter of APIs >>>> net/nfp: change the parameter of reconfig >>>> net/nfp: extract the MAC address data field >>>> net/nfp: rename parameter in related logic >>>> drivers: add the common ctrl module >>>> drivers: add the nfp common module >>>> drivers: move queue logic to common module >>>> drivers: move platform module to common library >>>> drivers: move device module to common library >>>> drivers/vdpa: introduce the NFP vDPA library >>>> drivers: add the basic framework of vDPA PMD >>>> vdpa/nfp: add the logic of remap PCI memory >>>> vdpa/nfp: add the hardware init logic >>>> drivers: add the datapath update logic >>>> vdpa/nfp: add the notify related logic >>>> vdpa/nfp: add nfp vDPA device operations >>>> doc: add the common and vDPA document >>>> >>> >>> Overall pretty clean set, but there are a few minor issues, commented >>> on patches. >>> >>> >>> Also can you please address checkpatch warnings: >>> >>> ### [PATCH] drivers: add the datapath update logic >>> >>> Warning in drivers/vdpa/nfp/nfp_vdpa.c: >>> Using __atomic_xxx built-ins, prefer rte_atomic_xxx >>> >> >> Oh, Sorry, we choose '__atomic_xxx' because we see the document in >> https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html?highlig >> ht=atomic%20operations%20use%20c11%20atomic%20builtins#atomic- >> operations-use-c11-atomic-builtins. >> Maybe we misunderstood it, we will change to the `rte_atomic_xxx` in next >> version, thanks. > > As the notes in the 'doc/guides/rel_notes/deprecation.rst': > --- > rte_atomicNN_xxx: These APIs do not take memory order parameter. This does > not allow for writing optimized code for all the CPU architectures supported > in DPDK. DPDK has adopted the atomic operations from > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. These > operations must be used for patches that need to be merged in 20.08 onwards. > This change will not introduce any performance degradation. > --- > The '__atomic_xxx' is the preferred choice? So maybe it's the > 'checkpatches.sh' should update? > And seems there are many logics using the '__atomic_xxx'. > > Spend some time and confused about this now. > What is the right APIs I should use? > Please make it clear, thanks. >
Atomics usage got a few updates by time, if I remember correct: first there was DPDK rte_atomicNN_xxx APIs, later guidance updated to prefer compiler builtins, and recently guidance updated to use C11 defined functions. And now there are 'rte_atomic_xxx()' APIs, underneath they use "compiler builtins" or "C11 functions" based on 'enable_stdatomic' config option and of course tool-chain support. That is the reason of complexity in the checkpatch script. @Tyler, @David, @Honnappa, what is the latest, up to date, guidance in the atomic APIs usage? @Honnappa, is the deprecation notice Chaoyong highlighted still valid? Should we update it?
