From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id E1BBB95EA for ; Tue, 23 Dec 2014 10:28:15 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 23 Dec 2014 01:24:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="503041737" Received: from unknown ([10.243.20.17]) by orsmga003.jf.intel.com with SMTP; 23 Dec 2014 01:23:30 -0800 Received: by (sSMTP sendmail emulation); Tue, 23 Dec 2014 09:28:09 +0025 Date: Tue, 23 Dec 2014 09:28:08 +0000 From: Bruce Richardson To: Neil Horman Message-ID: <20141223092808.GB10244@bricha3-MOBL3> References: <1419266844-4848-1-git-send-email-bruce.richardson@intel.com> <1698504.LDQKkGMxYZ@xps13> <20141222173306.GA11568@bricha3-MOBL3> <20141222174709.GE26669@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141222174709.GE26669@hmsreliant.think-freely.org> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support 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: Tue, 23 Dec 2014 09:28:16 -0000 On Mon, Dec 22, 2014 at 12:47:09PM -0500, Neil Horman wrote: > On Mon, Dec 22, 2014 at 05:33:07PM +0000, Bruce Richardson wrote: > > On Mon, Dec 22, 2014 at 06:02:53PM +0100, Thomas Monjalon wrote: > > > Hi Bruce, > > > > > > Callbacks, as hooks for applications, give more flexibility and are > > > generally a good idea. > > > In DPDK the main issue will be to avoid performance degradation. > > > I see you use "unlikely" for callback branching. > > > Could we reduce more the impact of this test by removing the queue array, > > > i.e. having port-wide callbacks instead of per-queue callbacks? > > > > I can give that a try, but I don't see it making much difference if any. The > > main thing to avoid with branching is branch mis-prediction, which should not > > be a problem here, as the user is not going to be adding or removing callbacks > > between each RX and TX call, making the branches highly predictable - i.e. always > > go the same way. > I was going to ask about exactly that. You say no one will be adding/removing > callbacks between RX/TX calls, but you don't know that, people will try to do so > at some point. You should add a check so that callbacks can only be > registered/unregistered on stopped queues, otherwise this is extreemely racy. > it won't impact performance to do so, and will save a good deal of debugging > down the road at some point. > > Neil > Actually, I think it's worthwhile being able to do exactly that - add/remove callbacks on the fly, if possible. Doing the add in a race-free manner is probably easy enough, but doing the delete may well be more tricky. For now, though, it might indeed be as well to limit it to stopped queues. If we can do the dynamic add/remove of callbacks, then that can lead to all sorts of interesting runtime instrumentation possibilities using multiprocess support. /Bruce