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 1E2A643A4E; Fri, 2 Feb 2024 10:22:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A0C1E42DC3; Fri, 2 Feb 2024 10:22:33 +0100 (CET) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by mails.dpdk.org (Postfix) with ESMTP id 473884026E for ; Fri, 2 Feb 2024 10:22:32 +0100 (CET) Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-42a9f4935a6so23335501cf.1 for ; Fri, 02 Feb 2024 01:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706865751; x=1707470551; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ohWZpiR9KSemcFQpky75CspfOJ+Y92XUmMfUlBuDwnw=; b=dxKwhy55eaCywe4LI1Pb5LQC7oMFWRatZpCA7F5MjSFe46WZArQ5OYVNnib7DEjbta 3YBcj3YSTKn53Qs13mlEmFFXsUvs7wPnDvlboYtQftRnNMmrXyd+s3TO+BzJ6Zwso7WF Zmud3XG96awe5n3zVZr1jAb1a/F7DIW3o3mfNGWXVdoh2eAwMcc5idcOpJeFmom/wUph 4r2tu6BByG6n2podTEp8uS0UBtgSxLu7+xDKQlAXoq4+dXtZbUrHQ5wipgjIGyOFTO6c U2k+jxAQZxZJXZp3cKkrMZjRuERPLXGxl8PFl5Ov9QM+OmcIwcVW3ykixZr7QplOYcA5 RBYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706865751; x=1707470551; 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=ohWZpiR9KSemcFQpky75CspfOJ+Y92XUmMfUlBuDwnw=; b=Q7oSl9WwWdn0fk8QT9/XBVh+KA2omeUtocuYqSKcvMCvAUNP1mNdQ7CgsiqiKOMpaM QoeOt8jbdmyhYOBwgBpzJDYWoRaYdzgonNFOM5U3v+DDBgiXs9LbeFAlj03UaawVAFVI nX8kBlGf0EAsQmIRQG+CD/rSY+BwzdvmLx/xDzTk+Epmj8q8LhIuPz4X1NZIKb6AEee0 6Mld6UXe+qwMw989eC9HOjfaiMIjXdiIwiwu1vJed77pg4KhPS5XKEZAW5IB9e2T6Noq 8uVgbVclByHCXHXQdVdBSnLIgBJ/2NXx+vP8DnM191CZgborALffp+XmHQFW8+Ht0Q03 SSEw== X-Gm-Message-State: AOJu0YwiFF5OwEZhOUc5iC4nkoG/YLzag/u126a0Z4bRybZJG7eZuETz rh0672O2J6mShq5U9TOM9oF+xJ+XWUFDeLXcQqAYeUqc3wHt6TNdxcLMUbKhciCUTYhXYwrX11+ PUn+L6ftsEb1eLPBgafOoePlD/L4= X-Google-Smtp-Source: AGHT+IGerlfLDvxBCJrCswcZ335fVA3WXv86rXq+mGb5dwMDlWGO3FOkwxmc/wmhFp9+3sMLRbAKTGEaqd/d5yNuoaQ= X-Received: by 2002:a05:622a:1a0a:b0:42a:7450:85e with SMTP id f10-20020a05622a1a0a00b0042a7450085emr2688384qtb.23.1706865751518; Fri, 02 Feb 2024 01:22:31 -0800 (PST) MIME-Version: 1.0 References: <20240118134557.73172-1-bruce.richardson@intel.com> <20240119174346.108905-1-bruce.richardson@intel.com> <20240119174346.108905-12-bruce.richardson@intel.com> <211a59b9-095d-418e-be82-b49f4e5d1d00@lysator.liu.se> In-Reply-To: From: Jerin Jacob Date: Fri, 2 Feb 2024 14:52:05 +0530 Message-ID: Subject: Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields To: Bruce Richardson Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , jerinj@marvell.com, dev@dpdk.org, mattias.ronnblom@ericsson.com, abdullah.sevincer@intel.com, sachin.saxena@oss.nxp.com, hemant.agrawal@nxp.com, pbhagavatula@marvell.com, pravin.pathak@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Feb 1, 2024 at 10:33=E2=80=AFPM Bruce Richardson wrote: > > On Wed, Jan 24, 2024 at 12:34:50PM +0100, Mattias R=C3=B6nnblom wrote: > > On 2024-01-19 18:43, Bruce Richardson wrote: > > > Clarify the meaning of the NEW, FORWARD and RELEASE event types. > > > For the fields in "rte_event" struct, enhance the comments on each to > > > clarify the field's use, and whether it is preserved between enqueue = and > > > dequeue, and it's role, if any, in scheduling. > > > > > > Signed-off-by: Bruce Richardson > > > --- > > > > > > As with the previous patch, please review this patch to ensure that t= he > > > expected semantics of the various event types and event fields have n= ot > > > changed in an unexpected way. > > > --- > > > lib/eventdev/rte_eventdev.h | 105 ++++++++++++++++++++++++++-------= --- > > > 1 file changed, 77 insertions(+), 28 deletions(-) > > > > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.= h > > > index cb13602ffb..4eff1c4958 100644 > > > --- a/lib/eventdev/rte_eventdev.h > > > +++ b/lib/eventdev/rte_eventdev.h > > > > > /** > > > @@ -1473,53 +1475,100 @@ struct rte_event { > > > /**< Targeted flow identifier for the enqueue and > > > * dequeue operation. > > > * The value must be in the range of > > > - * [0, nb_event_queue_flows - 1] which > > > + * [0, @ref rte_event_dev_config.nb_event_queue_f= lows - 1] which > > > > The same comment as I had before about ranges for unsigned types. > > > Actually, is this correct, does a range actually apply here? > > I thought that the number of queue flows supported was a guide as to how > internal HW resources were to be allocated, and that the flow_id was alwa= ys > a 20-bit value, where it was up to the scheduler to work out how to map > that to internal atomic locks (when combined with queue ids etc.). It > should not be up to the app to have to do the range limiting itself! On CNXK HW, it supports 20bit value. I am not sure about other HW. That is the reason I add this configuration parameter by allowing HW to be configured if it is NOT free. > > /Bruce