> Clarify (for dummies): > "Use of RTE_PTR_ALIGN [...] > + with integer types > should use [...]"
I'll add a new line to be more explicit. > > +#define PLT_PTR_UNQUAL RTE_PTR_UNQUAL > > The PLT_PTR_UNQUAL macro is only used in drivers/common/cnxk/roc_cpt_debug.c; > but I think it can be avoided by changing the frag_info variable from "struct > cpt_frag_info_s *frag_info;" to "const struct cpt_frag_info_s *frag_info;". > Then you don't need to add the PLT_PTR_UNQUAL macro. Done. > > +#define PLT_INT_PTR(intptr) ((void *)(uintptr_t)(intptr)) > > Like I didn't like the RTE_INT_PTR macros, I also don't like the > PLT_INT_PTR() macro. Please get rid of it. > If an address variable is uintptr_t type, can't you cast it to void* and > still use PLT_PTR_ADD()? Done. > Is using RTE_PTR_DIFF required here? Or can the code be unchanged? Good catch, I will fix this and review RTE_PTR_DIFF usage. RTE_PTR_ALIGN_CEIL is losing the ptr argument type by going through RTE_PTR_ADD, so it results "error: invalid operands to binary - (have ‘void *’ and ‘char *’)". I will fix the PTR_ALIGN macros to preserve return type consistently and also avoid void* cast which may impact optimizations that are alignment aware (required by RTE_PTR_[ADD|SUB] bcz result isn't known to be aligned). > > + if (addr) > > Correction: if (addr != NULL) > > > + munmap(RTE_PTR_ALIGN_FLOOR(addr, page_size), page_size); Done. > Do we also need __rte_assume(ext_mem->buf_ptr != NULL) for when building > without RTE_ENABLE_ASSERT? > If so, remember any other RTE_ASSERT()s ensuring non-NULL for RTE_PTR_ADD(). Sounds good, will do.
