From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f182.google.com (mail-wj0-f182.google.com [209.85.210.182]) by dpdk.org (Postfix) with ESMTP id 7CD87F72 for ; Mon, 28 Nov 2016 12:30:57 +0100 (CET) Received: by mail-wj0-f182.google.com with SMTP id xy5so112956220wjc.0 for ; Mon, 28 Nov 2016 03:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=XO2/Z/I3EkwujlF9mufUsof0AxTiQx9sntC4FrHeweo=; b=1Mx3qgjAJrec+7l6fQtOyLKKhA1VSczsHiBloM5tvNfx0pTokdRBoDS9ZX5QGUiyNg gth1YtymEDpUJMZJQWpuvaL26f6LemRaku938kbB76i2f7w2r5rV+JHiJkn4LlhIvZqZ ECQcoTV9ElfYSjkyb/qo7PbeKiQkWHyyTmHE9UFFQMaEELyRbi9pAuW4SllFKhIpJx3E rUwMANBCJZ5hjGxv1614CPPu/bB4W4ePf2bHJUmKhQCWyG/EsBgocthpHKnALqQrqHNb Om/BVTPQdLd7g5OTQBgjLzvLH2YKkX/iOqlTIz15rRRQ5854bsyaYihLtoideNyndb8I CaKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=XO2/Z/I3EkwujlF9mufUsof0AxTiQx9sntC4FrHeweo=; b=UqfeCCW7I3BUrwUq4bor7Uhc2f8sNm2blD37f0UCPbViwa81mJ4xRfFg4M0Q2W+1YD 5WpU0AQHPJ9eK2taoocVjvW7x7v1jUF+3t5nfyd0h1Vl/ZmVKccv4lMwm2Hd6vg+cR5N Ny7DRDwgWvlFiDGvX6yx7ntiAG4T0nMdXhWVjYt5LndyVjLuQ/i3bL1J1oJ9msWPLS/a UPwNuqBRfoTq85dd02t5MmwEQfvLRfseaA+o/oEtSb7BxYHaicKMLhBYHphxY1nFBzC9 ai8h6kYeRRfnQun7WjqQILSZ/znc8hg19o+g3a/pmEKJGoqIHJ/iIjwWV7/xHULEdtXu UqFw== X-Gm-Message-State: AKaTC015FZcG2W0XO8kgJarL6hXJuxIbqj+iZ49SATjf81zBxmbs8We9Vs1nlN+cP/qvDirN X-Received: by 10.194.10.165 with SMTP id j5mr18132156wjb.119.1480332657334; Mon, 28 Nov 2016 03:30:57 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id i15sm61949398wjs.16.2016.11.28.03.30.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 03:30:56 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Cc: Jerin Jacob , dev@dpdk.org, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, gage.eads@intel.com Date: Mon, 28 Nov 2016 12:30:55 +0100 Message-ID: <4715149.1G8ErmreiM@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20161128091610.GB168972@bricha3-MOBL3.ger.corp.intel.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161126025454.GA13886@svelivela-lt.caveonetworks.com> <20161128091610.GB168972@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 11:30:58 -0000 2016-11-28 09:16, Bruce Richardson: > On Sat, Nov 26, 2016 at 08:24:55AM +0530, Jerin Jacob wrote: > > On Fri, Nov 25, 2016 at 11:00:53AM +0000, Bruce Richardson wrote: > > > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote: > > > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote: > > > > > 2016-11-24 07:29, Jerin Jacob: > > > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote: > > > > > > > 2016-11-18 11:14, Jerin Jacob: > > > > > > > > +Eventdev API - EXPERIMENTAL > > > > > > > > +M: Jerin Jacob > > > > > > > > +F: lib/librte_eventdev/ > > > > > > > > > > > > > > > I don't think there is any portability issue here, I can explain. > > > > > > > > The application level, we have two more use case to deal with non burst > > > > variant > > > > > > > > - latency critical work > > > > - on dequeue, if application wants to deal with only one flow(i.e to > > > > avoid processing two different application flows to avoid cache trashing) > > > > > > > > Selection of the burst variants will be based on > > > > rte_event_dev_info_get() and rte_event_dev_configure()(see, max_event_port_dequeue_depth, > > > > max_event_port_enqueue_depth, nb_event_port_dequeue_depth, nb_event_port_enqueue_depth ) > > > > So I don't think their is portability issue here and I don't want to waste my > > > > CPU cycles on the for loop if application known to be working with non > > > > bursts variant like below > > > > > > > > > > If the application is known to be working on non-burst varients, then > > > they always request a burst-size of 1, and skip the loop completely. > > > There is no extra performance hit in that case in either the app or the > > > driver (since the non-burst driver always returns 1, irrespective of the > > > number requested). > > > > Hmm. I am afraid, There is. > > On the app side, the const "1" can not be optimized by the compiler as > > on downside it is function pointer based driver interface > > On the driver side, the implementation would be for loop based instead > > of plain access. > > (compiler never can see the const "1" in driver interface) > > > > We are planning to implement burst mode as kind of emulation mode and > > have a different scheme for burst and nonburst. The similar approach we have > > taken in introducing rte_event_schedule() and split the responsibility so > > that SW driver can work without additional performance overhead and neat > > driver interface. > > > > If you are concerned about the usability part and regression on the SW > > driver, then it's not the case, application will use nonburst variant only if > > dequeue_depth == 1 and/or explicit case where latency matters. > > > > On the portability side, we support both case and application if written based > > on dequeue_depth it will perform well in both implementations.IMO, There is > > no another shortcut for performance optimized application running on different > > set of model.I think it is not an issue as, in event model as each cores > > identical and main loop can be changed based on dequeue_depth > > if needs performance(anyway mainloop will be function pointer based). > > > > Ok, I think I see your point now. Here is an alternative suggestion. > > 1. Keep the single user API. > 2. Have both single and burst function pointers in the driver > 3. Call appropriately in the eventdev layer based on parameters. For > example: > > rte_event_dequeue_burst(..., int num) > { > if (num == 1 && single_dequeue_fn != NULL) > return single_dequeue_fn(...); > return burst_dequeue_fn(...); > } > > This way drivers can optionally special-case the single dequeue case - > the function pointer check will definitely be predictable in HW making > that a near-zero-cost check - while not forcing all drivers to do so. > It also reduces the public API surface, and gives us a single enqueue > and dequeue function. +1