[RFC PATCH v2 01/33] eal: add more min/max helpers
Bruce Richardson
bruce.richardson at intel.com
Mon Nov 10 09:58:50 CET 2025
On Mon, Nov 10, 2025 at 09:53:22AM +0100, Morten Brørup wrote:
> > From: fengchengwen [mailto:fengchengwen at huawei.com]
> >
> > Acked-by: Chengwen Feng <fengchengwen at huawei.com>
> >
> > On 11/7/2025 11:49 PM, Bruce Richardson wrote:
> > > From: Stephen Hemminger <stephen at 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 at networkplumber.org>
> > > Signed-off-by: Bruce Richardson <bruce.richardson at intel.com>
>
> With or without suggested additions,
> Acked-by: Morten Brørup <mb at smartsharesystems.com>
>
More information about the dev
mailing list