[PATCH v20] eal: RTE_PTR_ADD/SUB API improvements

[Scott Mitchell]

> 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.