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 E136C43A3C; Thu, 1 Feb 2024 17:21:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C08DB42E7B; Thu, 1 Feb 2024 17:21:07 +0100 (CET) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by mails.dpdk.org (Postfix) with ESMTP id D5ED042E79 for ; Thu, 1 Feb 2024 17:21:06 +0100 (CET) Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-42a4516ec5dso8432231cf.3 for ; Thu, 01 Feb 2024 08:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706804466; x=1707409266; 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=YF7ffUHvxf/wShGUbQGyRjmBVxXXfue4ZGbY76BWaPQ=; b=ka/pM+8mKh/2EECUXtj2u8eQRWb+rWgRuZoct3Dx8xVYM44RNSz6VCQxXY8l9vLj4J 0x5UYtUbp61WsYFwhLv75hO06sxeW7JhsH+SCpEIFRs+kccff+GlsToa0KaFlA2hN8jh OJjW0SVhFwsASHu3Z3IPxHIl9YHzRpYkxrq52Ya2XodU/IhTKPlBB3KMkr0FQWevExUN XNPu2fIycFCcYxVvI0WUOEHtI1NPy3Fd7vNTnDzov6McuV6Xv6simMhvpTUWZ2ug2s63 DWS5Eer7hMJQn89TnD1U6cfYx3MfXqrBgsHaCLqfwQnRXsV7THmgVyKrc6m5vS4U/vpt B8uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706804466; x=1707409266; 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=YF7ffUHvxf/wShGUbQGyRjmBVxXXfue4ZGbY76BWaPQ=; b=JymD+b57GKaWKYjaeomX21gaMZ0fQUHumPmNoQ7ASxcZr0OamQOQSqLoVFMP3vyv2d E1tu50O5mSK4yg6i+EDecEGarXe8Jn//HQgnADjQ4bhJF0xZCS0PZsYVtPeVxU+UIvCq y3I92m791YOJQFOpdiwbiP6V0NrLbKHdecZymGWJoyqM9yxtFfO+RjVmeLx20jzRylrB hlbLqegCmBSVbmGHTUQI3j0IVmAvR92j0GeOg69AVssQaf5HBMWA6ASocAu0o7aH5kEy 5uagZM6aDk6xtjpu7VQ1f7R1xbucXRrgvDP2HBUkiZF2bNMpM0+ak4wpG6QJUm+V3d73 ExaQ== X-Gm-Message-State: AOJu0YyIflGZjm/SIwZtq3Q7rtMWRMriM5GovHXjaBO+bGSkcIUbTMeD /9xKSpYYneS1CGJ1mOLj38Ir6+ij5lRnmLL1f3zES9PeyEwH+Xz9a86qHrongf/XpMDYHmK/KDB cUiisF8jXNtA2pj/lOIs3LFY7bHo= X-Google-Smtp-Source: AGHT+IHog1jqzblW4kRNVC7yQAqs0i79IlXqraciSkbL/mziFKNEhAelSTnOk5xWleM346vFBGJoBwcUK8RzBlV09rU= X-Received: by 2002:ac8:5e52:0:b0:42b:ef45:788a with SMTP id i18-20020ac85e52000000b0042bef45788amr3678546qtx.15.1706804466106; Thu, 01 Feb 2024 08:21:06 -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 21:50:39 +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 8:54=E2=80=AFPM Bruce Richardson wrote: > > On Thu, Feb 01, 2024 at 08:30:26PM +0530, Jerin Jacob wrote: > > 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 enqueu= e 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(-) > > > > > > > > > > > > > > #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_ATOM= IC* > > > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_= ATOMIC > > > > * then this function hints the scheduler that the user has comple= ted critical > > > > * section processing in the current atomic context. > > > > * The scheduler is now allowed to schedule events from the same f= low from > > > > @@ -1442,21 +1446,19 @@ struct rte_event_vector { > > > > * performance, but the user needs to design carefully the split i= nto critical > > > > * vs non-critical sections. > > > > * > > > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDE= RED* > > > > - * then this function hints the scheduler that the user has done a= ll that need > > > > - * to maintain event order in the current ordered context. > > > > - * The scheduler is allowed to release the ordered context of this= port and > > > > - * avoid reordering any following enqueues. > > > > - * > > > > - * Early ordered context release may increase parallelism and thus= system > > > > - * performance. > > > > > > Before I do up a V3 of this patchset, I'd like to try and understand = a bit > > > 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 diff= erent > > > things here. > > > > > > For me, RELEASE for ordered queues should mean much the same as for a= tomic > > > queues - it means that the event being released is to be "dropped" fr= om the > > > 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 f= or > > > 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 t= o go > > > through all flows and mark as skipped all reordered slots awaiting re= turned > > > 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 everyth= ing > > > automatically anyway? > > > > > > Jerin, I believe you were the author of the original text, can you pe= rhaps > > > 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. > > > Thanks for the reply. Just to confirm my understanding - the RELEASE > applies to the event that is being skipped/dropped, which in a burst-mode > of operation i.e. when nb_dequeued > 1, other events may still be enqueue= d > from that burst and reordered appropriately. Correct? Yes. That's my understanding too. > > /Bruce