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 C11995A45 for ; Wed, 20 May 2015 02:19:29 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 19 May 2015 17:19:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,461,1427785200"; d="scan'208";a="495781834" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by FMSMGA003.fm.intel.com with ESMTP; 19 May 2015 17:19:28 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 19 May 2015 17:19:28 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.213]) by fmsmsx120.amr.corp.intel.com ([169.254.15.202]) with mapi id 14.03.0224.002; Tue, 19 May 2015 17:19:27 -0700 From: "Wiles, Keith" To: "Richardson, Bruce" , "dev@dpdk.org" Thread-Topic: [RFC PATCHv2 0/2] pktdev as wrapper type Thread-Index: AQHQjAe4pa/LWPoZHUqUgS/gDqQgqp2Dq+cAgACTl4A= Date: Wed, 20 May 2015 00:19:27 +0000 Message-ID: References: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com> <20150519113112.GA10700@bricha3-MOBL3> In-Reply-To: <20150519113112.GA10700@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.129.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <670C2B4EAF424142AB5E9EC72894591F@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 20 May 2015 00:19:30 -0000 It looks fine to me. On 5/19/15, 7:31 AM, "Richardson, Bruce" wrote: >On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote: >> Hi all, >>=20 >> 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. >>=20 >> 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=20 >> 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=20 >> 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. >>=20 >> 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. >>=20 >> Comments/thoughts welcome. >>=20 >> 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