From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 28651F72
 for <dev@dpdk.org>; Thu, 24 Nov 2016 13:26:30 +0100 (CET)
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by orsmga104.jf.intel.com with ESMTP; 24 Nov 2016 04:26:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.31,543,1473145200"; d="scan'208";a="35091793"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64])
 by orsmga005.jf.intel.com with SMTP; 24 Nov 2016 04:26:27 -0800
Received: by  (sSMTP sendmail emulation); Thu, 24 Nov 2016 12:26:26 +0000
Date: Thu, 24 Nov 2016 12:26:26 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>, dev@dpdk.org,
 harry.van.haaren@intel.com, hemant.agrawal@nxp.com, gage.eads@intel.com
Message-ID: <20161124122626.GA123652@bricha3-MOBL3.ger.corp.intel.com>
References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com>
 <1479447902-3700-2-git-send-email-jerin.jacob@caviumnetworks.com>
 <3691745.y1f1NvKTEv@xps13>
 <20161124015912.GA13508@svelivela-lt.caveonetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161124015912.GA13508@svelivela-lt.caveonetworks.com>
Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?=
 =?iso-8859-1?Q?opment?= Ireland Ltd.
User-Agent: Mutt/1.7.1 (2016-10-04)
Subject: Re: [dpdk-dev] [PATCH 1/4] eventdev: introduce event driven
 programming model
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Thu, 24 Nov 2016 12:26:31 -0000

On Thu, Nov 24, 2016 at 07:29:13AM +0530, Jerin Jacob wrote:
> On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:

Just some comments on mine triggered by Thomas comments?

<snip>
> > + */
> > > +static inline int
> > > +rte_event_enqueue(uint8_t dev_id, uint8_t port_id, struct rte_event *ev)
> > 
> > Is it really needed to have non-burst variant of enqueue/dequeue?
> 
> Yes. certain HW can work only with non burst variants.

In those cases is it not acceptable just to have the dequeue_burst
function return 1 all the time? It would allow apps to be more portable
between burst and non-burst varients would it not.

> > 
> > > +/**
> > > + * Converts nanoseconds to *wait* value for rte_event_dequeue()
> > > + *
> > > + * If the device is configured with RTE_EVENT_DEV_CFG_PER_DEQUEUE_WAIT flag then
> > > + * application can use this function to convert wait value in nanoseconds to
> > > + * implementations specific wait value supplied in rte_event_dequeue()
> > 
> > Why is it implementation-specific?
> > Why this conversion is not internal in the driver?
> 
> This is for performance optimization, otherwise in drivers
> need to convert ns to ticks in "fast path"
> 
> > 
Is that really likely to be a performance bottleneck. I would expect
modern cores to fly through basic arithmetic in a negligable amount of
cycles?

/Bruce