[PATCH v3 5/6] examples/qos_sched: fix lcore ID restriction

[Tummala, Sivaprasad]

[AMD Official Use Only - General]

Hi Stephen,

> -----Original Message-----
> From: Yigit, Ferruh <Ferruh.Yigit at amd.com>
> Sent: Tuesday, January 9, 2024 8:47 PM
> To: Stephen Hemminger <stephen at networkplumber.org>; Tummala, Sivaprasad
> <Sivaprasad.Tummala at amd.com>
> Cc: david.hunt at intel.com; anatoly.burakov at intel.com; jerinj at marvell.com;
> radu.nicolau at intel.com; gakhil at marvell.com; cristian.dumitrescu at intel.com;
> konstantin.ananyev at huawei.com; dev at dpdk.org; stable at dpdk.org; Bruce
> Richardson <bruce.richardson at intel.com>
> Subject: Re: [PATCH v3 5/6] examples/qos_sched: fix lcore ID restriction
>
> On 12/20/2023 4:31 PM, Stephen Hemminger wrote:
> > On Wed, 20 Dec 2023 07:45:00 +0100
> > Sivaprasad Tummala <sivaprasad.tummala at amd.com> wrote:
> >
> >> diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
> >> index e97273152a..22fe76eeb5 100644
> >> --- a/examples/qos_sched/args.c
> >> +++ b/examples/qos_sched/args.c
> >> @@ -182,10 +182,10 @@ app_parse_flow_conf(const char *conf_str)
> >>
> >>    pconf->rx_port = vals[0];
> >>    pconf->tx_port = vals[1];
> >> -  pconf->rx_core = (uint8_t)vals[2];
> >> -  pconf->wt_core = (uint8_t)vals[3];
> >> +  pconf->rx_core = (uint16_t)vals[2];
> >> +  pconf->wt_core = (uint16_t)vals[3];
> >>    if (ret == 5)
> >> -          pconf->tx_core = (uint8_t)vals[4];
> >> +          pconf->tx_core = (uint16_t)vals[4];
> >>    else
> >>            pconf->tx_core = pconf->wt_core;
> >>
> >> --
> >
> > Not sure why cast is even needed, assigning uint32_t to uint16_t is
> > not going to generate a warning with current compiler settings.
> >
>
> I was assuming compiler will complain when assigning uint32_t to uint16_t, but it
> seems '-Wconversion' compiler flag is required for this warning.
> Enabling this flag for DPDK build causes lots of warnings, I wonder if we should add
> a new buildtype in meson that enables this flag.
>
>
> And except from compiler warning, I think it is good to keep explicit cast where
> assignment can cause change of value. This at worst can work as documentation
> that assignment between different types done intentionally.

I would prefer to keep the explicit conversion for consistency.
Please let me know if you think otherwise.