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 0454D43A3F; Thu, 1 Feb 2024 16:00:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CD9D8402E9; Thu, 1 Feb 2024 16:00:54 +0100 (CET) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by mails.dpdk.org (Postfix) with ESMTP id 68C10402E4 for ; Thu, 1 Feb 2024 16:00:53 +0100 (CET) Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-3bd72353d9fso813324b6e.3 for ; Thu, 01 Feb 2024 07:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706799652; x=1707404452; 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=C01X+k+aO7OMFEeKTgXcjlGjZPDN5IqJwpkR4XGSKKQ=; b=j2efdttc4EqOuwnSKcUe7msrH7UFr1ev7y05qASycPC2QiEx2HIOpHfFbEdRPjZ7Kk ToIIEA+Ey67u8D7vmA3TOEWcVEq8YmbIPl+VGNRAiEKk/ryJ3Jud72B3lObSkEhrDWn+ EHoXG5wt/GAnSzhLkB/1j5C2X7i6FIhxsoO6mV4E8vh6gCFkxdjBV6TLo5Hj1IkPe7Be jBwm9NSsUvJwDAIu+hpGJKHo+EJmplKKyxxyw3pH6DYoiNLwNYU0yR6tENUvnVq6ohp4 EZP6EAwGN8uVW3ePYsNui3gVyxey9XkgL1m7/UIOY29p7yIA2eV3XC2fiOb7awWmmSJV uTxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706799652; x=1707404452; 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=C01X+k+aO7OMFEeKTgXcjlGjZPDN5IqJwpkR4XGSKKQ=; b=VJBh6yUQztaPdRgasQqMuu6EqHNn/i5D+jm3jr/vQifSSH0TtC6txBkJDnuiSkjohd vCQBoTkWgiWkZrKLkblDpC1k1Fr2tSp9opSICzvKQYGrUFo3HbPrfXUITSS1FdTjgWvu +Yeocnyk3eUwX9c98dLH6wm2kmoYieDPzUYP9tf0s7MbMFbB92mYBvU3wPhkBPGIjlu8 zNy7crf6D1icQSXe9tQ3qCCgnu7bbCNujQgvw4ZXM9lILxuBmeceYHAQAagO6nNcjhkB oIbdjvvKlgDRf9wOjv4DZqZiZ2MbuuDZqr2A8T/NEBQhoa5y+rnp/zSD157myJ1OEnxN ox6w== X-Gm-Message-State: AOJu0Ywq2NEwES/shn6OUvu4Mu2kv+5bHY0WYeRA0z7SjrzuP4n6tL4i dowMvrKM8vZMSRAmO+Grcma7ygKlEiEsVXXe2iK32LPoAXN3/B+3AW+askeBNbVtWbIvAQgBPJY kB3noVREb27iySDyAnYIJg6+yhfA= X-Google-Smtp-Source: AGHT+IEg1QXOU5ApKaISnmxunE/9Xn3MIdv0ZJUy+mCJmo4glTfvkocOZmvwmoPDPm5JdqniwWqPFRMYzXzsaZCHUdc= X-Received: by 2002:a05:6808:2e99:b0:3bf:bb23:c94d with SMTP id gt25-20020a0568082e9900b003bfbb23c94dmr27505oib.55.1706799652551; Thu, 01 Feb 2024 07:00:52 -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> In-Reply-To: From: Jerin Jacob Date: Thu, 1 Feb 2024 20:30:26 +0530 Message-ID: Subject: Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields To: Bruce Richardson Cc: dev@dpdk.org, jerinj@marvell.com, 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 3:05=E2=80=AFPM Bruce Richardson wrote: > > On Fri, Jan 19, 2024 at 05:43:46PM +0000, 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 an= d > > 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(-) > > > > > > #define RTE_EVENT_OP_RELEASE 2 > > /**< Release the flow context associated with the schedule type. > > * > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC* > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOM= IC > > * then this function hints the scheduler that the user has completed = critical > > * section processing in the current atomic context. > > * The scheduler is now allowed to schedule events from the same flow = from > > @@ -1442,21 +1446,19 @@ struct rte_event_vector { > > * performance, but the user needs to design carefully the split into = critical > > * vs non-critical sections. > > * > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED* > > - * then this function hints the scheduler that the user has done all t= hat need > > - * to maintain event order in the current ordered context. > > - * The scheduler is allowed to release the ordered context of this por= t and > > - * avoid reordering any following enqueues. > > - * > > - * Early ordered context release may increase parallelism and thus sys= tem > > - * performance. > > Before I do up a V3 of this patchset, I'd like to try and understand a bi= t > more what was meant by the original text for reordered here. The use of > "context" is very ambiguous, since it could refer to a number of differen= t > things here. > > For me, RELEASE for ordered queues should mean much the same as for atomi= c > queues - it means that the event being released is to be "dropped" from t= he > point of view of the eventdev scheduler - i.e. any atomic locks held for > that event should be released, and any reordering slots for it should be > skipped. However, the text above seems to imply that when we release one > event it means that we should stop reordering all subsequent events for > that port - which seems wrong to me. Especially in the case where > reordering may be done per flow, does one release mean that we need to go > through all flows and mark as skipped all reordered slots awaiting return= ed > events from that port? If this is what is intended, how is it better than > just doing another dequeue call from the port, which releases everything > automatically anyway? > > Jerin, I believe you were the author of the original text, can you perhap= s > clarify? Other PMD maintainers, can any of you chime in with current > supported behaviour when enqueuing a release of an ordered event? If N number of cores does rte_event_dequeue_burst() and got the same flow, and it is scheduled as RTE_SCHED_TYPE_ORDERED and then irrespective of the timing downstream rte_event_enqueue_burst() invocation any core. Upon rte_event_enqueue_burst() completion, the events will be enqueued the downstream queue in the ingress order. Assume, one of the core, calls RTE_EVENT_OP_RELEASE in between dequeue and enqueue, then that event no more eligible for the ingress order maintenance. > Ideally, I'd like to see this simplified whereby release for ordered > behaves like that for atomic, and refers to the current event only, (and > drop any mention of contexts). > > Thanks, > /Bruce