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 C4D7C45AA8; Fri, 4 Oct 2024 06:47:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 99DF2402DD; Fri, 4 Oct 2024 06:47:37 +0200 (CEST) Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by mails.dpdk.org (Postfix) with ESMTP id 9603A402DD for ; Fri, 4 Oct 2024 06:47:36 +0200 (CEST) Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-7a99fde9f1dso143661185a.2 for ; Thu, 03 Oct 2024 21:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728017256; x=1728622056; 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=OwYDue6SR0FGd7iXJxSiaDnv9R/7XI4tF0uZnuDvtek=; b=FeilPrRI6VLsoYMYUo1RwnVLbqCB6tzDRPYVcVrd+BMQg9cOxTq1DRSeh649/uQ7cD vVejV6JFWPnczaF5ovJ17ZzoHnew5wJSUA2W486GCD/KCjf7Bo7AsG5XXWTsFAGpq93L 24H22JJ8XlClZnh1OzAJ+eK531TlKBjPfVEIaJMjg1IBwOF6xRDkaSMQDoVnnIxFeEWS iDlMjfH0uZ7MgJ3fnxNgKIGMlEmBqTeUYWraIWIF6B8IEIsWgTAlI66N+cDPCPqy7E+N an7ar3W4SJ6xXqWiak+jcLyHqo+dH9RsRSEjg2j3K9SF4myx3bby49UjnlzwkHrsmyHl sZnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728017256; x=1728622056; 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=OwYDue6SR0FGd7iXJxSiaDnv9R/7XI4tF0uZnuDvtek=; b=KtS11F+SKR9XMfcE6xy7gUtG7E6SeFx8wJdNt7i/fdvOBh97KBmmWMLbPEmmIAJtX3 VMByUKey9+BIGjkpc2v5g1tUjN14J99w1AygLxQimwlvtUuqLAqHVdpVDN62c54YjRdR /LspB3zwmw7AKrfxRhwbAjByr6FDA0JONGB3WqoZLH/nwl4y6Lu6K6yngn898dtXhPBi NjN1J5WW3+yIdG1uX/A8uRoOXmJfHsD0m37jX6vSeXMXt7C0suRC9T6iuwOULZxLrW8C DRcNIQaENwgv6cEN1x29m7qjbWYm+R/uNd8mNP4Pm6BbiQn6Hf4pW4uu/2gkHQ/auDv5 zdVg== X-Forwarded-Encrypted: i=1; AJvYcCV7VQzAAWgIbYXGuhF9J5fFKANSf5yvSU0wGDupC0r+LQhQNVnp13l6RJmaPDwm6KzGXQM=@dpdk.org X-Gm-Message-State: AOJu0YzOeYM0xhsIhNEau/NVC0Y0hft+9DcyfIirs0cJS1b1uyjfO4g1 SRJPHXrySi6a0nW3/ft7i6uFZSnxiVKeB6Kz/kLO/Kox+y6TXL74sADSrd0FHv8vcVCfNQgUoBz a98KwNrrGttKWYyegnudFqdkJm4Y= X-Google-Smtp-Source: AGHT+IEIQePjiA/vfOPmtRPEG3RmRdWEWb+WxQjYkal/Gju32GjCCwlivXNd62IkbnqewIg99XcAZOaeCJlqG2LFYw4= X-Received: by 2002:a05:620a:4155:b0:79d:6d7d:e5b3 with SMTP id af79cd13be357-7ae6f488406mr281414785a.42.1728017255671; Thu, 03 Oct 2024 21:47:35 -0700 (PDT) MIME-Version: 1.0 References: <20241001061411.2537-1-pbhagavatula@marvell.com> <20241001131901.7920-1-pbhagavatula@marvell.com> <20241001131901.7920-2-pbhagavatula@marvell.com> In-Reply-To: <20241001131901.7920-2-pbhagavatula@marvell.com> From: Jerin Jacob Date: Fri, 4 Oct 2024 10:17:09 +0530 Message-ID: Subject: Re: [PATCH v4 1/6] eventdev: introduce event pre-scheduling To: pbhagavatula@marvell.com Cc: jerinj@marvell.com, sthotton@marvell.com, abdullah.sevincer@intel.com, hemant.agrawal@nxp.com, sachin.saxena@oss.nxp.com, harry.van.haaren@intel.com, mattias.ronnblom@ericsson.com, liangma@liangbit.com, peter.mccarthy@intel.com, dev@dpdk.org 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 Tue, Oct 1, 2024 at 7:44=E2=80=AFPM wrote: > > From: Pavan Nikhilesh > > Event pre-scheduling improves scheduling performance by assigning events > to event ports in advance when dequeues are issued. > The dequeue operation initiates the pre-schedule operation, which complet= es > in parallel without affecting the dequeued event flow contexts and > dequeue latency. > > Event devices can indicate pre-scheduling capabilities using > `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE` and > `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE` via the event device info > function `info.event_dev_cap`. > > Applications can select the pre-schedule type and configure it through > `rte_event_dev_config.preschedule_type` during `rte_event_dev_configure`. > > The supported pre-schedule types are: > * `RTE_EVENT_DEV_PRESCHEDULE_NONE` - No pre-scheduling. > * `RTE_EVENT_DEV_PRESCHEDULE` - Always issue a pre-schedule on dequeue. > * `RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE` - Delay issuing pre-schedule unti= l > there are no forward progress constraints with the held flow contexts. > > Signed-off-by: Pavan Nikhilesh eventdev PMD maintainers, Is anyone planning to review this series more? The general outlook of the patch looks good to me. I will have a few minor comments. If there are no other comments, I will merge early next week as RC1 PR. > --- > app/test/test_eventdev.c | 108 ++++++++++++++++++++ > doc/guides/eventdevs/features/default.ini | 1 + > doc/guides/prog_guide/eventdev/eventdev.rst | 22 ++++ > doc/guides/rel_notes/release_24_11.rst | 8 ++ > lib/eventdev/rte_eventdev.h | 48 +++++++++ > 5 files changed, 187 insertions(+) > > > +Event Pre-scheduling > +~~~~~~~~~~~~~~~~~~~~ > + > +Event pre-scheduling improves scheduling performance by assigning events= to event ports in advance > +when dequeues are issued. > +The `rte_event_dequeue_burst` operation initiates the pre-schedule opera= tion, which completes > +in parallel without affecting the dequeued event flow contexts and deque= ue latency. > +On the next dequeue operation, the pre-scheduled events are dequeued and= pre-schedule is initiated > +again. > + > +An application can use event pre-scheduling if the event device supports= it at either device > +level or at a individual port level. > +The application can check pre-schedule capability by checking if ``rte_e= vent_dev_info.event_dev_cap`` can -> must > +has the bit ``RTE_EVENT_DEV_CAP_PRESCHEDULE`` set, if present pre-schedu= ling can be enabled at device > +configuration time by setting appropriate pre-schedule type in ``rte_eve= nt_dev_config.preschedule``. Missing RTE_EVENT_DEV_CAP_PRESCHEDULE_ADAPTIVE cap doc. > + > +Currently, the following pre-schedule types are supported: I think, we can remove =E2=80=9CCurrently=E2=80=9D > + * ``RTE_EVENT_DEV_PRESCHEDULE_NONE`` - No pre-scheduling. > + * ``RTE_EVENT_DEV_PRESCHEDULE`` - Always issue a pre-schedule when dequ= eue is issued. > + * ``RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE`` - Issue pre-schedule when dequ= eue is issued and there are > + no forward progress constraints. > + > > +#define RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE (1ULL << 16) > +/**< Event device supports event pre-scheduling. > + * > + * When this capability is available, the application can enable event p= re-scheduling on the event > + * device to pre-schedule events to a event port when `rte_event_dequeue= _burst()` > + * is issued. > + * The pre-schedule process starts with the `rte_event_dequeue_burst()` = call and the > + * pre-scheduled events are returned on the next `rte_event_dequeue_burs= t()` call. > + * > + * @see rte_event_dev_configure() > + */ Doxygen for the new enum is missing. > > +typedef enum { > + RTE_EVENT_DEV_PRESCHEDULE_NONE =3D 0, Explicit 0 is not needed. > + /* Disable pre-schedule across the event device or on a given eve= nt port. Use Doxygen format across the series, i.e /**< > + * @ref rte_event_dev_config.preschedule_type > + */ > + RTE_EVENT_DEV_PRESCHEDULE, > + /* Enable pre-schedule always across the event device or a given = event port. > + * @ref rte_event_dev_config.preschedule_type > + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE > + */ > + RTE_EVENT_DEV_PRESCHEDULE_ADAPTIVE, > + /* Enable adaptive pre-schedule across the event device or a give= n event port. > + * Delay issuing pre-schedule until there are no forward progress= constraints with > + * the held flow contexts. > + * @ref rte_event_dev_config.preschedule_type > + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE > + */ > +} rte_event_dev_preschedule_type_t; > + > /** Event device configuration structure */ > struct rte_event_dev_config { > uint32_t dequeue_timeout_ns; > @@ -752,6 +795,11 @@ struct rte_event_dev_config { > * optimized for single-link usage, this field is a hint for how = many > * to allocate; otherwise, regular event ports and queues will be= used. > */ > + rte_event_dev_preschedule_type_t preschedule_type; Please add ABI changes in doc/guides/rel_notes/release_24_11.rst > + /**< Event pre-schedule type to use across the event device, if s= upported. > + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE > + * @see RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE > + */ > }; > > /** > -- > 2.25.1 >