From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [RFC] [PATCH v2] libeventdev: event driven
 programming model framework for DPDK
Date: Fri, 14 Oct 2016 18:22:51 +0530
Message-ID: <20161014125250.GA6900@localhost.localdomain>
References: <20161005072451.GA2358@localhost.localdomain>
 <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <CAKb83kahuY-m52QEsTbL6aPAQxsQ1qPyWcphRienRQiaipVnnA@mail.gmail.com>
 <20161014092607.GA16828@localhost.localdomain>
 <DB5PR04MB1605D0F7FAAEB2484BEFF76689DF0@DB5PR04MB1605.eurprd04.prod.outlook.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Bill Fischofer <bill.fischofer@linaro.org>, "dev@dpdk.org" <dev@dpdk.org>,
 "thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>,
 "bruce.richardson@intel.com" <bruce.richardson@intel.com>,
 "narender.vangati@intel.com" <narender.vangati@intel.com>,
 "gage.eads@intel.com" <gage.eads@intel.com>
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-DM3-obe.outbound.protection.outlook.com
 (mail-dm3nam03on0051.outbound.protection.outlook.com [104.47.41.51])
 by dpdk.org (Postfix) with ESMTP id 3808F952
 for <dev@dpdk.org>; Fri, 14 Oct 2016 14:53:17 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <DB5PR04MB1605D0F7FAAEB2484BEFF76689DF0@DB5PR04MB1605.eurprd04.prod.outlook.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Oct 14, 2016 at 10:30:33AM +0000, Hemant Agrawal wrote:

> > > Am I reading this correctly that there is no way to support an
> > > indefinite waiting capability? Or is this just saying that if a timed
> > > wait is performed there are min/max limits for the wait duration?
> > 
> > Application can wait indefinite if required. see
> > RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration option.
> > 
> > Trivial application may not need different wait values on each dequeue.This is a
> > performance optimization opportunity for implementation.
> 
>  Jerin, It is irrespective of wait configuration, whether you are using per device wait or per dequeuer wait. 
>  Can the value of MAX_U32 or MAX_U64 be treated as infinite weight? 

That will be yet another check in the fast path in the implementation, I
think, for more fine-grained wait scheme. Let application configure the device
with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT so that the application can have
two different function pointer-based implementation for dequeue function
if required.

With RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT configuration, implicitly
MAX_U64 becomes infinite weight as the wait is uint64_t.
I can add this info in v3 if required.

Jerin

> 
> >