From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 02B8FFE5 for ; Mon, 11 May 2015 18:29:44 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 11 May 2015 09:29:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,408,1427785200"; d="scan'208";a="569584089" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by orsmga003.jf.intel.com with ESMTP; 11 May 2015 09:29:42 -0700 Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com [10.237.217.45]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id t4BGTfdL028814; Mon, 11 May 2015 17:29:42 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id t4BGTfdn012656; Mon, 11 May 2015 17:29:41 +0100 Received: (from bricha3@localhost) by sivswdev01.ir.intel.com with id t4BGTfTC012652; Mon, 11 May 2015 17:29:41 +0100 From: Bruce Richardson To: dev@dpdk.org Date: Mon, 11 May 2015 17:29:39 +0100 Message-Id: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com> X-Mailer: git-send-email 1.7.4.1 Subject: [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: Mon, 11 May 2015 16:29:45 -0000 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 config/common_bsdapp | 5 + config/common_linuxapp | 5 + examples/pktdev/Makefile | 57 +++++++++++ examples/pktdev/basicfwd.c | 221 +++++++++++++++++++++++++++++++++++++++++ lib/Makefile | 1 + lib/librte_pktdev/Makefile | 53 ++++++++++ lib/librte_pktdev/rte_pktdev.h | 200 +++++++++++++++++++++++++++++++++++++ 7 files changed, 542 insertions(+) create mode 100644 examples/pktdev/Makefile create mode 100644 examples/pktdev/basicfwd.c create mode 100644 lib/librte_pktdev/Makefile create mode 100644 lib/librte_pktdev/rte_pktdev.h -- 2.1.0