[v2] eal: Pointer alignment check improvements

  Checking a const pointer for alignment would emit a warning about the
const qualifier being discarded.

No need to calculate the aligned pointer; just check the last bits of the
pointer.

v2:
- Remove compiler attribute ((const)) from function;
  it was a coding style issue.

Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
---
 lib/eal/include/rte_common.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
  

On Thu, Sep 22, 2022 at 01:44:13PM +0200, Morten Brørup wrote:
> Checking a const pointer for alignment would emit a warning about the
> const qualifier being discarded.
> 
> No need to calculate the aligned pointer; just check the last bits of the
> pointer.
> 
> v2:
> - Remove compiler attribute ((const)) from function;
>   it was a coding style issue.
> 
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/eal/include/rte_common.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 2e22c1b955..ed81e0db0a 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -404,9 +404,9 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
>   *   True(1) where the pointer is correctly aligned, false(0) otherwise
>   */
>  static inline int
> -rte_is_aligned(void *ptr, unsigned align)
> +rte_is_aligned(const void * const __rte_restrict ptr, const unsigned int align)
>  {
> -	return RTE_PTR_ALIGN(ptr, align) == ptr;
> +	return ((uintptr_t)ptr & (align - 1)) == 0;

Are we confident that in future, or using come compiler settings, we won't
get an error due to using "uintptr_t" rather than "const uintptr_t" in the
cast? I would put a const in there myself, just to be safe.

A further point, only-semi-related to this patch, which is fine as-is:
looking at the code for the various macros in rte_common.h:
* The various macros for working on pointers can can probably be converted
  to functions, since they don't need to work with variable-sized types.
* We can then see about properly ensuring those inline functions are
  const-correct.

/Bruce
  

On Thu, Sep 22, 2022 at 12:52:42PM +0100, Bruce Richardson wrote:
> On Thu, Sep 22, 2022 at 01:44:13PM +0200, Morten Brørup wrote:
> > Checking a const pointer for alignment would emit a warning about the
> > const qualifier being discarded.
> > 
> > No need to calculate the aligned pointer; just check the last bits of the
> > pointer.
> > 
> > v2:
> > - Remove compiler attribute ((const)) from function;
> >   it was a coding style issue.
> > 
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> >  lib/eal/include/rte_common.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> > index 2e22c1b955..ed81e0db0a 100644
> > --- a/lib/eal/include/rte_common.h
> > +++ b/lib/eal/include/rte_common.h
> > @@ -404,9 +404,9 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
> >   *   True(1) where the pointer is correctly aligned, false(0) otherwise
> >   */
> >  static inline int
> > -rte_is_aligned(void *ptr, unsigned align)
> > +rte_is_aligned(const void * const __rte_restrict ptr, const unsigned int align)
> >  {
> > -	return RTE_PTR_ALIGN(ptr, align) == ptr;
> > +	return ((uintptr_t)ptr & (align - 1)) == 0;
> 
> Are we confident that in future, or using come compiler settings, we won't
> get an error due to using "uintptr_t" rather than "const uintptr_t" in the
> cast? I would put a const in there myself, just to be safe.
> 
> A further point, only-semi-related to this patch, which is fine as-is:
> looking at the code for the various macros in rte_common.h:
> * The various macros for working on pointers can can probably be converted
>   to functions, since they don't need to work with variable-sized types.
> * We can then see about properly ensuring those inline functions are
>   const-correct.
> 
Actually, on further investigation in trying this, it appears that the
macros are used in a number of places with integer data too, despite the
"PTR" in the name, so things are best alone for now, I think.

/Bruce
  

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 22 September 2022 13.59
> 
> On Thu, Sep 22, 2022 at 12:52:42PM +0100, Bruce Richardson wrote:
> > On Thu, Sep 22, 2022 at 01:44:13PM +0200, Morten Brørup wrote:
> > > Checking a const pointer for alignment would emit a warning about
> the
> > > const qualifier being discarded.
> > >
> > > No need to calculate the aligned pointer; just check the last bits
> of the
> > > pointer.
> > >
> > > v2:
> > > - Remove compiler attribute ((const)) from function;
> > >   it was a coding style issue.
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > ---
> > >  lib/eal/include/rte_common.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/eal/include/rte_common.h
> b/lib/eal/include/rte_common.h
> > > index 2e22c1b955..ed81e0db0a 100644
> > > --- a/lib/eal/include/rte_common.h
> > > +++ b/lib/eal/include/rte_common.h
> > > @@ -404,9 +404,9 @@ static void
> __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
> > >   *   True(1) where the pointer is correctly aligned, false(0)
> otherwise
> > >   */
> > >  static inline int
> > > -rte_is_aligned(void *ptr, unsigned align)
> > > +rte_is_aligned(const void * const __rte_restrict ptr, const
> unsigned int align)
> > >  {
> > > -	return RTE_PTR_ALIGN(ptr, align) == ptr;
> > > +	return ((uintptr_t)ptr & (align - 1)) == 0;
> >
> > Are we confident that in future, or using come compiler settings, we
> won't
> > get an error due to using "uintptr_t" rather than "const uintptr_t"
> in the
> > cast? I would put a const in there myself, just to be safe.

Good idea.

> >
> > A further point, only-semi-related to this patch, which is fine as-
> is:
> > looking at the code for the various macros in rte_common.h:
> > * The various macros for working on pointers can can probably be
> converted
> >   to functions, since they don't need to work with variable-sized
> types.
> > * We can then see about properly ensuring those inline functions are
> >   const-correct.

The problem with const in a function parameter is the ripple effect: all the underlying functions must also use const.

I generally prefer using const where possible, but the ripple effect often makes it difficult.

> >
> Actually, on further investigation in trying this, it appears that the
> macros are used in a number of places with integer data too, despite
> the
> "PTR" in the name, so things are best alone for now, I think.

Even the macros that also exist without "PTR" in the name? (Example, please.)

Instead of providing multiple macros for essentially doing the same thing to different types, we could use __builtin_choose_expr [1] to support a variety of types in the macros. This built-in can be used as a workaround for not being able to use C++, where the same function name can be used by multiple functions with different parameter types.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

I was also wondering why the rte_is_aligned function doesn't have "ptr" in its name, because it cannot be used for integer types. Changing rte_is_aligned to a macro using __builtin_choose_expr could solve this. But I don't think such a patch will be popular, so I chose to stick with the simple fix.

-Morten
  

On Thu, Sep 22, 2022 at 01:44:13PM +0200, Morten Brørup wrote:
> Checking a const pointer for alignment would emit a warning about the
> const qualifier being discarded.
> 
> No need to calculate the aligned pointer; just check the last bits of the
> pointer.
> 
> v2:
> - Remove compiler attribute ((const)) from function;
>   it was a coding style issue.
> 
> Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  lib/eal/include/rte_common.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 2e22c1b955..ed81e0db0a 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -404,9 +404,9 @@ static void __attribute__((destructor(RTE_PRIO(prio)), used)) func(void)
>   *   True(1) where the pointer is correctly aligned, false(0) otherwise
>   */
>  static inline int
> -rte_is_aligned(void *ptr, unsigned align)
> +rte_is_aligned(const void * const __rte_restrict ptr, const unsigned int align)
>  {
> -	return RTE_PTR_ALIGN(ptr, align) == ptr;
> +	return ((uintptr_t)ptr & (align - 1)) == 0;
>  }
>  
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
  

On Fri, Sep 23, 2022 at 10:25 AM Bruce Richardson
<bruce.richardson@intel.com> wrote:
> On Thu, Sep 22, 2022 at 01:44:13PM +0200, Morten Brørup wrote:
> > Checking a const pointer for alignment would emit a warning about the
> > const qualifier being discarded.
> >
> > No need to calculate the aligned pointer; just check the last bits of the
> > pointer.
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Applied, thanks.