From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 992D9A0597; Thu, 9 Apr 2020 15:32:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8E5AB1C23D; Thu, 9 Apr 2020 15:32:58 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id 14BF71C216 for ; Thu, 9 Apr 2020 15:32:57 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id w1so3821107iot.7 for ; Thu, 09 Apr 2020 06:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s/NuEd+AWJU02m2x+f7btohum1JWwfk/09wMekwqkJA=; b=bo3xYaEpeijPaxr/cXVAHz/FC2ueKu1VRj4wlZ65CRSSyNE9jkSFW8zxQJ/EJbxfJv UZzhoIzZ454sMzUdFV2n9ngghlDaa8B3v8svQHXDgeFcIVQGAx+6wiy3Wi9y3lIoW/oR y2VrREGueLnLVWk8SXi6bj48Yfmy4j6sn/udeaoeCBbGX5YUfmqDJWlc2U276Mvczpok hEjJYfcXhSKrWKP9EtiByhTGZ1mGwhXX53u6dz3+mgs/prCwFrAME4U9+iCTVvbxYz9K b95r5dOHw6n1AI6rhKG4g2sw1cQHobfLZ51QnoJb5rg1JvxsntKSya8lIV1ld/bYB0T8 6Nxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s/NuEd+AWJU02m2x+f7btohum1JWwfk/09wMekwqkJA=; b=OYv2NHVBKpKW5fluaPHb3haQyD3cJONnwUAIXeeXvwPOvBpoVyY2V7/i3+spBJJk2H G3nx2Fi+twM8/H85OcYFtCXamjdcbQq+o0P2KCLXByFI7lgZU0VlylHptiypcfzi+iq9 SzLvdItr3hc2JM3V13Vpz/uyddlPb58xn2p0akEE7NozOlw/IJm1fltSxzBCieJ7zTQO GAo5U2wsFnSCHgk1LmTyqwuLrEpR5IcN43vU+E5eTod1pDQrAtz6Du1C6NBoRUJTkdeY Ehyr47yvTaf08o3i8Ws1YPuWbB8UNDcMFck5ttlmIen7uN0WXBHJsI7aCD3wenMNWBXe R/EA== X-Gm-Message-State: AGi0Pubsza4GvcDuiDr6Rc8avPSFnPTRm1iXCmCyhQVlWyoTocJh1s/P hL+nVFVfanFaze3l3/yYT+ckUDAe7cJ4RyqXK8o= X-Google-Smtp-Source: APiQypKjuaKVSQUWEuRu02M+zNw+bFY+ZJ+Zor1mDR1F6pZvdBeFDEemnbGPYBDTLDTLUW4cSO7P+QoGEiXlsJpPtf8= X-Received: by 2002:a5e:de05:: with SMTP id e5mr11955542iok.1.1586439176146; Thu, 09 Apr 2020 06:32:56 -0700 (PDT) MIME-Version: 1.0 References: <20200408175655.18879-1-mattias.ronnblom@ericsson.com> <86ff8b8f-7865-7fe2-f853-e88d2a64347d@ericsson.com> In-Reply-To: <86ff8b8f-7865-7fe2-f853-e88d2a64347d@ericsson.com> From: Jerin Jacob Date: Thu, 9 Apr 2020 19:02:40 +0530 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: dpdk-dev , Jerin Jacob , Gage Eads , Bruce Richardson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC 1/3] eventdev: allow for event devices requiring maintenance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 9, 2020 at 5:51 PM Mattias R=C3=B6nnblom wrote: > > On 2020-04-08 21:36, Jerin Jacob wrote: > > On Wed, Apr 8, 2020 at 11:27 PM Mattias R=C3=B6nnblom > > wrote: > >> Extend Eventdev API to allow for event devices which require various > >> forms of internal processing to happen, even when events are not > >> enqueued to or dequeued from a port. > >> > >> Signed-off-by: Mattias R=C3=B6nnblom > >> --- > >> lib/librte_eventdev/rte_eventdev.h | 65 ++++++++++++++++++++++++= ++ > >> lib/librte_eventdev/rte_eventdev_pmd.h | 14 ++++++ > >> 2 files changed, 79 insertions(+) > >> > >> diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/= rte_eventdev.h > >> index 226f352ad..d69150792 100644 > >> --- a/lib/librte_eventdev/rte_eventdev.h > >> +++ b/lib/librte_eventdev/rte_eventdev.h > >> @@ -289,6 +289,15 @@ struct rte_event; > >> * single queue to each port or map a single queue to many port. > >> */ > >> > >> +#define RTE_EVENT_DEV_CAP_REQUIRES_MAINT (1ULL << 9) > >> +/**< Event device requires calls to rte_event_maintain() during > > This scheme would call for DSW specific API handling in fastpath. > > > Initially this would be so, but buffering events might yield performance > benefits for more event devices than DSW. > > > In an application, it's often convenient, but sub-optimal from a > performance point of view, to do single-event enqueue operations. The > alternative is to use an application-level buffer, and the flush this > buffer with rte_event_enqueue_burst(). If you allow the event device to > buffer, you get the simplicity of single-event enqueue operations, but > without taking any noticeable performance hit. IMO, It is better to aggregate the burst by the application, as sending event by event to the driver to aggregate has performance due to cost function pointer overhead. Another concern is the frequency of calling rte_event_maintain() function b= y the application, as the timing requirements will vary differently by the driver to driver and application to application. IMO, It is not portable and I believe the application should not be aware of those details. If the driver needs specific maintenance function for any other reason then better to use DPDK SERVICE core infra. > > > >> + * periods when neither rte_event_dequeue_burst() nor > > The typical worker thread will be > > while (1) { > > rte_event_dequeue_burst(); > > ..proess.. > > rte_event_enqueue_burst(); > > } > > If so, Why DSW driver can't do the maintenance in driver context in > > dequeue() call. > > > > DSW already does maintenance on dequeue, and works well in the above > scenario. The typical worker does not need to care about the > rte_event_maintain() functions, since it dequeues events on a regular bas= is. > > > What this RFC addresses is the more atypical (but still fairly common) > case of a port being neither dequeued to or enqueued from on a regular > basis. The timer and ethernet rx adapters are examples of such. If it is an Adapter specific use case problem then maybe, we have an option to fix the problem in adapter specific API usage or in that area. > > > >> + * rte_event_enqueue_burst() are called on a port. This will allow th= e > >> + * event device to perform internal processing, such as flushing > >> + * buffered events, return credits to a global pool, or process > >> + * signaling related to load balancing. > >> + */ > >