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 C4ECDC35A for ; Fri, 17 Apr 2015 17:16:47 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 17 Apr 2015 08:16:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,595,1422950400"; d="scan'208";a="482250505" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by FMSMGA003.fm.intel.com with ESMTP; 17 Apr 2015 08:16:45 -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 t3HFGjLN030418; Fri, 17 Apr 2015 16:16:45 +0100 Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1]) by sivswdev01.ir.intel.com with ESMTP id t3HFGi3O028125; Fri, 17 Apr 2015 16:16:44 +0100 Received: (from bricha3@localhost) by sivswdev01.ir.intel.com with id t3HFGil0028121; Fri, 17 Apr 2015 16:16:44 +0100 From: Bruce Richardson To: dev@dpdk.org, keith.wiles@intel.com Date: Fri, 17 Apr 2015 16:16:40 +0100 Message-Id: <1429283804-28087-1-git-send-email-bruce.richardson@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1428954274-26944-1-git-send-email-keith.wiles@intel.com> References: <1428954274-26944-1-git-send-email-keith.wiles@intel.com> Subject: [dpdk-dev] [RFC PATCH 0/4] pktdev 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: Fri, 17 Apr 2015 15:16:48 -0000 Hi all, to continue this discussion a bit more, here is my, slightly different, slant on what a pktdev abstraction may look like. The primary objective I had in mind when drafting this is to provide the minimal abstraction that can be *easily* used as a common device abstraction for existing (and future) device types to be passed to dataplane code. The patchset demonstrates this by defining a minimal interface for pktdev - since I firmly believe the interface should be as small as possible - and then showing how that common interface can be used to unify rings and ethdevs under a common API for the datapath. I believe any attempt to unify things much beyond this to the control plane or setup phase is not worth doing - at least not initially - as at init time the code always needs to be aware of the underlying resource type in order to configure it properly for dataplane use. The overall objective I look to achieve is illustrated by the final patch in the series, which is a sample app where the same code is used for all cores, irrespective of the underlying device type. To get to that point, patch 1 defines the minimal API - just RX and TX. The .c file in the library is empty for simplicity, though I would see some functionality moving there when/if it makes sense e.g. the callback support from ethdev, as is done in Keith's patchset. Patch 2 then makes very minimal changes to ethdev to allow ethdevs to be used as pktdevs, and to make use of the pktdev functions when appropriate Patch 3 was, for me, the key test for this implementation - how hard was it to make an rte_ring usable as a pktdev too. Two single-line functions for RX/TX and a separate "converter" function proved to be all that was necessary here - and I believe simpler solutions may be possible too, as the extra structures allocated on conversion could be merged into the rte_ring structure itself and initialized on ring creation if we prefer that option. It is hoped/presumed that wrapping other structures, such as KNI, may prove to be just as easily done. [Not attempted yet - left as an exercise for the reader :-)]. Now, in terms of pktdev vs ethdev, there is nothing in this proposal that cannot also be done using ethdev AFAIK. However, pktdev as outlined here should make the process far easier than trying to create a full PMD for something. All NIC specific functions, including things like stop/start, are stripped out, as they don't make sense for an rte_ring or other software objects. Also, the other thing this provides is that we can move away from just using port ids. Instead in the same way as we now reference rings/mempools/KNIs etc via pointer, we can do the same with ethernet ports as pktdevs on the data path. There was discussion previously on moving beyond 8-bit port ids. If we look to use ethdev as a common abstraction, I feel that change will soon have to be made causing a large amount of code churn. Bruce Richardson (4): Add example pktdev implementation Make ethdev explicitly a subclass of pktdev add support for a ring to be a pktdev example app showing pktdevs used in a chain config/common_bsdapp | 5 + config/common_linuxapp | 5 + examples/pktdev/Makefile | 57 +++++++++++ examples/pktdev/basicfwd.c | 222 +++++++++++++++++++++++++++++++++++++++++ lib/Makefile | 1 + lib/librte_ether/rte_ethdev.h | 26 ++--- lib/librte_pktdev/Makefile | 56 +++++++++++ lib/librte_pktdev/rte_pktdev.c | 35 +++++++ lib/librte_pktdev/rte_pktdev.h | 144 ++++++++++++++++++++++++++ lib/librte_ring/rte_ring.c | 41 ++++++++ lib/librte_ring/rte_ring.h | 3 + 11 files changed, 582 insertions(+), 13 deletions(-) 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.c create mode 100644 lib/librte_pktdev/rte_pktdev.h -- 2.1.0