> > 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. > > > ### [PATCH] vdpa/nfp: add the notify related logic > > > > Warning in drivers/vdpa/nfp/nfp_vdpa.c: > > Using pthread functions, prefer rte_thread > > > > Okay, will revise in the next version. > > > ### [PATCH] vdpa/nfp: add nfp vDPA device operations > > > > Warning in drivers/vdpa/nfp/nfp_vdpa.c: > > Using __atomic_xxx built-ins, prefer rte_atomic_xxx > > > > > > And some typos: > > vdpa/nfp: add nfp vDPA device operations > > opetation > > Will change in next version, thanks.
