[AMD Official Use Only - General]
Hi,
> -----Original Message-----
> From: David Marchand <david.march...@redhat.com>
> Sent: Thursday, March 7, 2024 2:04 PM
> To: Tummala, Sivaprasad <sivaprasad.tumm...@amd.com>
> Cc: david.h...@intel.com; anatoly.bura...@intel.com; jer...@marvell.com;
> radu.nico...@intel.com; gak...@marvell.com; cristian.dumitre...@intel.com;
> Yigit,
> Ferruh <ferruh.yi...@amd.com>; konstantin.anan...@huawei.com;
> dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [PATCH 1/6] examples/l3fwd: fix lcore ID restriction
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Dec 18, 2023 at 8:49 AM Sivaprasad Tummala
> <sivaprasad.tumm...@amd.com> wrote:
> >
> > Currently the config option allows lcore IDs up to 255, irrespective
> > of RTE_MAX_LCORES and needs to be fixed.
>
> "needs to be fixed" ?
> I disagree on the principle.
> The examples were written with limitations, this is not a bug.
>
> >
> > The patch allows config options based on DPDK config.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
>
> Please remove this request for backport in the next revision.
>
> >
> > Signed-off-by: Sivaprasad Tummala <sivaprasad.tumm...@amd.com>
> > ---
> > examples/l3fwd/main.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index
> > 3bf28aec0c..847ded0ad2 100644
> > --- a/examples/l3fwd/main.c
> > +++ b/examples/l3fwd/main.c
> > @@ -99,7 +99,7 @@ struct parm_cfg parm_config; struct lcore_params {
> > uint16_t port_id;
> > uint8_t queue_id;
> > - uint8_t lcore_id;
> > + uint16_t lcore_id;
>
> lcore_id are stored as an unsigned int (so potentially 32bits) in EAL.
> Moving to uint16_t seems not enough.
Will fix this to be aligned to EAL. However, I don't think of a SOC/CPU with
more than
65536 cores/threads.
>
>
> > } __rte_cache_aligned;
> >
> > static struct lcore_params lcore_params_array[MAX_LCORE_PARAMS];
> > @@ -292,8 +292,8 @@ setup_l3fwd_lookup_tables(void) static int
> > check_lcore_params(void)
> > {
> > - uint8_t queue, lcore;
> > - uint16_t i;
> > + uint8_t queue;
> > + uint16_t i, lcore;
> > int socketid;
> >
> > for (i = 0; i < nb_lcore_params; ++i) { @@ -359,7 +359,7 @@
> > static int
> > init_lcore_rx_queues(void)
> > {
> > uint16_t i, nb_rx_queue;
> > - uint8_t lcore;
> > + uint16_t lcore;
> >
> > for (i = 0; i < nb_lcore_params; ++i) {
> > lcore = lcore_params[i].lcore_id; @@ -500,6 +500,8 @@
> > parse_config(const char *q_arg)
> > char *str_fld[_NUM_FLD];
> > int i;
> > unsigned size;
> > + unsigned int max_fld[_NUM_FLD] = {RTE_MAX_ETHPORTS,
>
> This change here is not described in the commitlog and introduces a bug.
OK! Will fix it
>
> In this example, queue_id is stored as a uint8_t.
> queue_id are stored as uint16_t in ethdev.
> Yet RTE_MAX_ETHPORTS can be larger than 255.
queue_id is already modified as uint16_t based on the earlier comment from
Konstantin.
The port_id is already uint16_t even if RTE_MAX_ETHPORTS exceeds 255.
I will fix the max_fld type to "uint32_t" to accommodate lcore.
>
>
> > + 255, RTE_MAX_LCORE};
> >
> > nb_lcore_params = 0;
> >
> > @@ -518,7 +520,8 @@ parse_config(const char *q_arg)
> > for (i = 0; i < _NUM_FLD; i++){
> > errno = 0;
> > int_fld[i] = strtoul(str_fld[i], &end, 0);
> > - if (errno != 0 || end == str_fld[i] || int_fld[i] >
> > 255)
> > + if (errno != 0 || end == str_fld[i] || int_fld[i] >
> > +
> > + max_fld[i])
> > return -1;
> > }
> > if (nb_lcore_params >= MAX_LCORE_PARAMS) { @@ -531,7
> > +534,7 @@ parse_config(const char *q_arg)
> > lcore_params_array[nb_lcore_params].queue_id =
> > (uint8_t)int_fld[FLD_QUEUE];
> > lcore_params_array[nb_lcore_params].lcore_id =
> > - (uint8_t)int_fld[FLD_LCORE];
> > + (uint16_t)int_fld[FLD_LCORE];
> > ++nb_lcore_params;
> > }
> > lcore_params = lcore_params_array;
> > --
> > 2.25.1
> >
>
> I did not check other patches in the series, but I suggest you revisit them
> in the
> light of those comments.
OK
>
>
> --
> David Marchand
Thanks & Regards,
Sivaprasad
