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 2A409436D1; Tue, 12 Dec 2023 13:48:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A930B42E18; Tue, 12 Dec 2023 13:48:16 +0100 (CET) Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) by mails.dpdk.org (Postfix) with ESMTP id 3E49242DB2 for ; Tue, 12 Dec 2023 13:48:14 +0100 (CET) Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-1f060e059a3so4226379fac.1 for ; Tue, 12 Dec 2023 04:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702385294; x=1702990094; 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=v2IAEq1zDBAvcePJVrG5wbxcuapBdcfXS808U4lblLE=; b=HX0Kt7wGMUZAC3kqZY+aH+BiLs53rjLogV4m7ggn98e3rGiU5n+zEh5ULZRuxSNbGI hDfiEycq5T1g9ZPZMal5qDAHOsZePmkSn3QO8G4xlRFFGF3e/Wi6WB79aae+7FUTy2Ok hzCkHrp4upTgHfBGK1ffXpyRCQoLGjBYtTfXU4bQcd3JqfRI+/720/tCP6uJfnFqCrGC 12N4sOvEwcvZHouyH4BiyPFYsLKjouoME/FWv7fXdOExeLCHhnJxtIqaYlSZlIAbQ0mr bfGD8qzg8e/cnr60hvATfk/4xCngRkDCsobg3BQWEuZB4sqi/rntZREK62NTBoERg/De PIhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702385294; x=1702990094; 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=v2IAEq1zDBAvcePJVrG5wbxcuapBdcfXS808U4lblLE=; b=O+OsJvG+NQEAr9n9NK1i1kdVNLyuJuFDSDhF48t6ofhQHCxQunHn5uhwJvC4FLSkbg 8ewHxYl1yPrL7wkTtEYLiSZ0eG0zqdE7ouUHIlkdQx2lhOPsxBAHDKathWDXTlHdGr1d zJyHVTLctCsmRzeW1GP6wo/xxm+/2ddn89Sl76xz46c1u20lmKNlJ1/0vuYnGe4RydmL q7rsf9aZt3iTOLTi3Li69DdDqLnsAC7AaAeRYtjSwiXOIDu6VL1Iwm7q+YE4CLknT1UX D1gEXN4c2BRVjOdYEmWdhm8OlDFGHEAMFkuca/ZrDe42JCr1/nvkveuYHIqRGqhNXwBn ESpQ== X-Gm-Message-State: AOJu0Yw96L/U/6UOGgrgSvjYLJ7zw2mfl7G+x6Qz12E9N/6qXorBYXVZ tsMa4o3vZI+JVMwz/Kxwhky5DA0pGnimrkoapNM= X-Google-Smtp-Source: AGHT+IHP7UUELhaGUKKdkos436gPFno0t+9gMCG5r/SnB3eTd3Dvs19euT5GTJUBiAIovzgYK5G/XBDx8FML+UO9NkQ= X-Received: by 2002:a05:6871:292:b0:1fb:75c:4007 with SMTP id i18-20020a056871029200b001fb075c4007mr7359491oae.103.1702385294017; Tue, 12 Dec 2023 04:48:14 -0800 (PST) MIME-Version: 1.0 References: <20231120172606.505579-1-bruce.richardson@intel.com> <20231121115437.96500-1-bruce.richardson@intel.com> <20231121115437.96500-3-bruce.richardson@intel.com> In-Reply-To: From: Jerin Jacob Date: Tue, 12 Dec 2023 18:17:47 +0530 Message-ID: Subject: Re: [PATCH 24.03 v2 2/9] eventdev: increase flexibility of all-types flag To: Bruce Richardson Cc: dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Jerin Jacob 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, Dec 12, 2023 at 4:58=E2=80=AFPM Bruce Richardson wrote: > > On Thu, Nov 23, 2023 at 09:37:58AM +0530, Jerin Jacob wrote: > > On Tue, Nov 21, 2023 at 5:25=E2=80=AFPM Bruce Richardson > > wrote: > > > > > > Rather than requiring that any device advertising the > > > RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES flag support all of atomic, ordered > > > and parallel scheduling, we can redefine the field so that it basical= ly > > > means that you don't need to specify the queue scheduling type at con= fig > > > time. Instead all types of supported events can be sent to all queues= . > > > > > > Suggested-by: Mattias R=C3=B6nnblom > > > Signed-off-by: Bruce Richardson > > > --- > > > lib/eventdev/rte_eventdev.h | 15 ++++++++++++--- > > > 1 file changed, 12 insertions(+), 3 deletions(-) > > > > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.= h > > > index d48957362c..1c5043de26 100644 > > > --- a/lib/eventdev/rte_eventdev.h > > > +++ b/lib/eventdev/rte_eventdev.h > > > @@ -250,11 +250,20 @@ struct rte_event; > > > * @see rte_event_dequeue_burst() > > > */ > > > #define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES (1ULL << 3) > > > -/**< Event device is capable of enqueuing events of any type to any = queue. > > > +/**< Event device is capable of accepting enqueued events, of any ty= pe > > > + * advertised as supported by the device, to all destination queues. > > > + * > > > + * When this capability is set, the "schedule_type" field of the > > > + * rte_event_queue_conf structure is ignored when a queue is being c= onfigured. > > > > can we also add something like below or so to above line > > > > rte_event_queue_conf structure is ignored when a queue is being > > configured instead rte_event::sched_type > > shall be used. > > > Preparing v3 now and including this doc change. However, I'm also wonderi= ng > about the correct behaviour when this flag is not set. When the flag is n= ot > set, the events enqueued should match the event type of the queue, but do > we need to enforce this, or should we? > > Couple of options: > 1. Actually enforce this, and state that it is an error to enqueue events > with another scheduling type. > 2. Explicitly not enforce this, and just state instead that the sched_typ= e > of events will be ignored. > > Personally, I'd tend very much towards #2. because: > * it's easier for the app, as they can ignore the sched_type field throug= h > the pipeline if they want, relying on each queues type to do the right > thing. This could be especially useful if they have fallback mechanisms > to e.g. configure a queue as atomic if reordered is not supported etc. > The downside is that for portable applications the sched type > should always be set anyway, but the app doesn't lose anything in this > case with #2 over #1. > > * It's easier and more performant for the drivers, since it's one less > check that should be performed on enqueue. The driver can just blindly > override the sched_type provided with the queue config version. > > I actually think an extension of #2 would also be nice to have for > portability, whereby an app could explicitly configure a queue to only ha= ve > a scheduling type - event if it's all-types-capable - and thereafter neve= r > have to set the sched_type field on events. The drivers would always > remember the queue-type and explicitly set that if necessary on enqueue > > Thoughts? HW queues with All-type support will be costly resources, so making a portable program we need to spare 3 queues instead of 1 queue. Considering the difference in eventdev capabilities, I see the most reliable option is end user focus on reusable packet processing stages. Have worker skeleton b= ased on HW device capabilities, as there are enough HW differences across event devices. That is the kind of theme followed in testeventdev. > /Bruce > > PS: Going to send v3 now anyway, based on feedback thus far. If we get > quick consensus on above, I can roll it into a v4, otherwise we can look = to Let's go with v3 now. Later we can discuss more on this latter. > clarify that situation in a separate patch later.