From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 57CBA43BA2 for ; Thu, 7 Mar 2024 09:34:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E2F442E39; Thu, 7 Mar 2024 09:34:25 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 67CB240295 for ; Thu, 7 Mar 2024 09:34:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709800463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdJfMltynZS38GQgk0Kr3FYtNK1PA6+oX4zOZFQwLK8=; b=MIXZvqO64yzlp7qP27MyerErcmRqsVxMVCYLvu+aQLX8puUQ1VURZ7m8xDkwG1z526Peq0 5pSak183FgZwfXuSuTwRGNs726SK9809hQMfMGUHYskd4IoAt94PHgmhQj4jPFbxBAFMw7 nFcBQSMDIKaeMNMt1tg3xvkDbcf08f0= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-463-Q-AelxdzNTuIx8tAeqiD9g-1; Thu, 07 Mar 2024 03:34:21 -0500 X-MC-Unique: Q-AelxdzNTuIx8tAeqiD9g-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-5133f2e0485so389920e87.0 for ; Thu, 07 Mar 2024 00:34:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709800460; x=1710405260; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rdJfMltynZS38GQgk0Kr3FYtNK1PA6+oX4zOZFQwLK8=; b=e7UFA+gZ7OOYGQZZ0Llbks4m18i6z7FeGpJ/fNp+XmQXuaQk28HPLnMSKeOdKy4nyW B36oB6jOADl51DtaTkquSICHog7oZrKq0QZH0P5ToOZWZqUc6eacJdEaqHFkUXrgy2RC Qqr4VGefFUTScyqo8Cpe71fUtPu+Iw9zjBXPQDBZAcLNo4Ln4pj261QGhkLA4eiYLTrZ m3ild73Yj8NbCgjSysSiHkqnxIXVzl1cUoihuMjLL0ZtI+eQupm2f1ZK8uddmVZQ3Ud1 kMXaPxhnJ8rEeuHwuv7miho8EHz+u3vPHL9oFVCX4pakDNvwnRHajg270fpH7A28Twx2 T8bQ== X-Forwarded-Encrypted: i=1; AJvYcCU9QX9aCBuqUTAjQEmGvf1PQsgAEJ6m0+finec3ZTV8LYzrnYXiej0pImGXpNwiRP8WcZyEpaLtIz1YQ7MHIig= X-Gm-Message-State: AOJu0Yz74om+3iKtgwnRQhmfZg4I5T90/wlM5tq9s0pR/w0zI3iUyo+k EkeD2cEOFPBGgM6MdZG1X1ZPKFDzGIXHN9IBHUkMLG5c4ugWBRwdbXJpnr9h2JoLmPWcHpAAWsU 8qyhZoBdmwACDg/X4oFIko5Yi5cBm/MexBRiqeYXhR9HrwJuzxmd5kyHBxgHspPOAYtGXOfpaV1 Y/pLahHcyEmgJdOd9GQjc= X-Received: by 2002:a05:6512:328e:b0:512:f389:d6e0 with SMTP id p14-20020a056512328e00b00512f389d6e0mr289064lfe.4.1709800460185; Thu, 07 Mar 2024 00:34:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IEvtmFWpwoKNT/huRUDrgGZO3vK6vk49r+8V8pXx8xaT4ZAjvI0lf+kHhPvlUU9PuBvXusa2d0rGMqgheab1U0= X-Received: by 2002:a05:6512:328e:b0:512:f389:d6e0 with SMTP id p14-20020a056512328e00b00512f389d6e0mr289055lfe.4.1709800459820; Thu, 07 Mar 2024 00:34:19 -0800 (PST) MIME-Version: 1.0 References: <20231218074905.42749-1-sivaprasad.tummala@amd.com> In-Reply-To: <20231218074905.42749-1-sivaprasad.tummala@amd.com> From: David Marchand Date: Thu, 7 Mar 2024 09:34:07 +0100 Message-ID: Subject: Re: [PATCH 1/6] examples/l3fwd: fix lcore ID restriction To: Sivaprasad Tummala Cc: david.hunt@intel.com, anatoly.burakov@intel.com, jerinj@marvell.com, radu.nicolau@intel.com, gakhil@marvell.com, cristian.dumitrescu@intel.com, ferruh.yigit@amd.com, konstantin.ananyev@huawei.com, dev@dpdk.org, stable@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Mon, Dec 18, 2023 at 8:49=E2=80=AFAM Sivaprasad Tummala 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: stable@dpdk.org Please remove this request for backport in the next revision. > > Signed-off-by: Sivaprasad Tummala > --- > 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. > } __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 =3D 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 =3D 0; i < nb_lcore_params; ++i) { > lcore =3D 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] =3D {RTE_MAX_ETHPORTS, This change here is not described in the commitlog and introduces a bug. 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. > + 255, RTE_MAX_LCORE}; > > nb_lcore_params =3D 0; > > @@ -518,7 +520,8 @@ parse_config(const char *q_arg) > for (i =3D 0; i < _NUM_FLD; i++){ > errno =3D 0; > int_fld[i] =3D strtoul(str_fld[i], &end, 0); > - if (errno !=3D 0 || end =3D=3D str_fld[i] || int_= fld[i] > 255) > + if (errno !=3D 0 || end =3D=3D str_fld[i] || int_= fld[i] > > + m= ax_fld[i]) > return -1; > } > if (nb_lcore_params >=3D MAX_LCORE_PARAMS) { > @@ -531,7 +534,7 @@ parse_config(const char *q_arg) > lcore_params_array[nb_lcore_params].queue_id =3D > (uint8_t)int_fld[FLD_QUEUE]; > lcore_params_array[nb_lcore_params].lcore_id =3D > - (uint8_t)int_fld[FLD_LCORE]; > + (uint16_t)int_fld[FLD_LCORE]; > ++nb_lcore_params; > } > lcore_params =3D 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. --=20 David Marchand