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 27A6B43A4E; Fri, 2 Feb 2024 10:45:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0726A402DC; Fri, 2 Feb 2024 10:45:38 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id B4B8C4026E for ; Fri, 2 Feb 2024 10:45:36 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7B7E31FF51 for ; Fri, 2 Feb 2024 10:45:36 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 6E26F1FFCC; Fri, 2 Feb 2024 10:45:36 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.4 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 10E922B; Fri, 2 Feb 2024 10:45:35 +0100 (CET) Message-ID: Date: Fri, 2 Feb 2024 10:45:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields Content-Language: en-US To: Bruce Richardson , jerinj@marvell.com Cc: 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 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> From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-02-01 18:02, Bruce Richardson wrote: > On Wed, Jan 24, 2024 at 12:34:50PM +0100, Mattias Rönnblom 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 the >>> expected semantics of the various event types and event fields have not >>> 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_flows - 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 always > 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! > Indeed, I also operated under this belief, which is reflected in DSW, which just takes the flow_id and (pseudo-)hash+mask it into the appropriate range. Leaving it to the app allows app-level attempts to avoid collisions between large flows, I guess. Not sure I think apps will (or even should) really do this.