From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6DC575A36 for ; Tue, 19 May 2015 13:31:16 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 19 May 2015 04:31:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,457,1427785200"; d="scan'208";a="495485410" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.63]) by FMSMGA003.fm.intel.com with SMTP; 19 May 2015 04:31:13 -0700 Received: by (sSMTP sendmail emulation); Tue, 19 May 2015 12:31:12 +0025 Date: Tue, 19 May 2015 12:31:12 +0100 From: Bruce Richardson To: dev@dpdk.org Message-ID: <20150519113112.GA10700@bricha3-MOBL3> References: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type 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, 19 May 2015 11:31:16 -0000 On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote: > Hi all, > > after a small amount of offline discussion with Marc Sune, here is an > alternative proposal for a higher-level interface - aka pktdev - to allow a > common Rx/Tx API across device types handling mbufs [for now, ethdev, ring > and KNI]. The key code is in the first patch fo the set - the second is an > example of a trivial usecase. > > What is different about this to previously: > * wrapper class, so no changes to any existing ring, ethdev implementations > * use of function pointers for RX/TX with an API that maps to ethdev > - this means there is little/no additional overhead for ethdev calls > - inline special case for rings, to accelerate that. Since we are at a > higher level, we can special case process some things if appropriate. This > means the impact to ring ops is one (predictable) branch per burst > * elimination of the queue abstraction. For the ring and KNI, there is no > concept of queues, so we just wrap the functions directly (no need even for > wrapper functions, the api's match so we can call directly). This also > means: > - adding in features per-queue, is far easier as we don't need to worry about > having arrays of multiple queues. For example: > - adding in buffering on TX (or RX) is easier since again we only have a > single queue. > * thread safety is made easier using a wrapper. For a MP ring, we can create > multiple pktdevs around it, and each thread will then be able to use their > own copy, with their own buffering etc. > > However, at this point, I'm just looking for general feedback on this as an > approach. I think it's quite flexible - even more so than the earlier proposal > we had. It's less proscriptive and doesn't make any demands on any other libs. > > Comments/thoughts welcome. > > Bruce Richardson (2): > Add example pktdev implementation > example app showing pktdevs used in a chain > Any comments on this RFC before I see about investing further time in it to clean it up a bit and submit as a non-RFC patchset for merge in 2.1? /Bruce