Re: [RFC PATCH v2 01/33] eal: add more min/max helpers

Bruce Richardson
2025-11-10T08:59:17Z

On Mon, Nov 10, 2025 at 09:53:22AM +0100, Morten Brørup wrote:
> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> >
> > Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> >
> > On 11/7/2025 11:49 PM, Bruce Richardson wrote:
> > > From: Stephen Hemminger <stephen@networkplumber.org>
> > >
> > > Add RTE_MIN3() to handle case of RTE_MIN(RTE_MIN(...)), and similarly
> > > add RTE_MAX3().
>
> Do we need RTE_MIN3_T()/RTE_MAX3_T() macros too?
>
> > > Change name of local temporary variables in RTE_MAX()
> > > to allow for combinations of RTE_MIN(RTE_MAX(...)) without causing
> > > shadow declaration warnings.
>
> Consider making the local temporary variables in RTE_MIN() more unique too, in case the macro is combined with some other macro also using _a and _b.
>

Yes, that's possible. If I remember, I'll try and tweak this again if I do
a new version of the set.

> <feature creep>
> Maybe an RTE_MINMAX(min,max,val) would be useful?
> Same about RTE_MINMAX_T(min,max,val,type)?
> </feature creep>
>

Not sure that is worth doing.

Also, the naming gets weird and confusing, is the "max" parameter the
parameter that would be passed to the MAX macro, i.e. the minimum value, or
the actual maximum value you want to clamp. Therefore, if we were to have
such an API, I'd avoid min-max in macro name entirely, and call it
"RTE_BOUND" for example.

Again, though, I don't think it's a high priority addition and won't do in
a new version of this set.

> > >
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> With or without suggested additions,
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>