From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id EA0875A8A for ; Mon, 20 Apr 2015 12:43:26 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 20 Apr 2015 03:43:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,609,1422950400"; d="scan'208";a="483097003" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.27]) by FMSMGA003.fm.intel.com with SMTP; 20 Apr 2015 03:43:18 -0700 Received: by (sSMTP sendmail emulation); Mon, 20 Apr 2015 11:43:16 +0025 Date: Mon, 20 Apr 2015 11:43:16 +0100 From: Bruce Richardson To: Marc Sune Message-ID: <20150420104316.GA9280@bricha3-MOBL3> References: <1428954274-26944-1-git-send-email-keith.wiles@intel.com> <1429283804-28087-1-git-send-email-bruce.richardson@intel.com> <553155C7.3000106@bisdn.de> <5534A1EE.4060905@bisdn.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5534A1EE.4060905@bisdn.de> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [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: Mon, 20 Apr 2015 10:43:27 -0000 On Mon, Apr 20, 2015 at 08:51:26AM +0200, Marc Sune wrote: > > > On 17/04/15 21:50, Wiles, Keith wrote: > >Hi Marc and Bruce, > > Hi Keith, Bruce, > > > > >On 4/17/15, 1:49 PM, "Marc Sune" wrote: > What I was proposing is to try to add the minimum common shared state in > order to properly demultiplex the RX/TX call and have a common set of > abstract calls (the pkt_dev type). In a way, I was proposing to deliberately > not have a shared struct rte_dev_data because I think the internals of the > "pkt_dev" can be very different across devices (e.g. queues in kni vs eth > port vs. crypto?). I treat the pkt_dev as a "black box" that conforms to > TX/RX API, leaving the developer of that device to define its internal > structures as it better suites the needs. I only use each of the specific > device type TX/RX APIs (external to us, pkt_dev library) in rte_pkt_dev.h. > This also simplifies the refactor required to eventually integrate the > rte_pkt_dev library and builds it "on top" of the existing APIs. > > The other important difference with both, Bruce and your approach, and mine > is the use of function pointers for RX/TX. I don't use them, which makes the > entire abstracted TX/RX (including the final RX/TX routines itself) > functions be "inlinable". > > Btw, I forgot to add something basic in the previous pseudo-code. The > different types have to be conditionally compiled according to compiled-in > DPDK libs: > > rte_pkt_dev.h: > > #include > > //Eth devices > #ifdef RTE_LIBRTE_ETHER > #include > #endif > > //KNI > #ifdef RTE_LIBRTE_KNI > #include > #endif > > //... > //Include PMD (and non-PMD) TX/RX headers... > > static inline uint16_t > rte_pkt_tx_burst(pkt_dev_t* dev, uint16_t queue_id, > struct rte_mbuf **tx_pkts, uint16_t nb_pkts) > { > switch (((struct rte_pkt_dev_data*)dev)->type){ > #ifdef RTE_LIBRTE_ETHER > case RTE_PKT_DEV_ETH: > struct rte_eth_dev* eth_dev = (struct rte_eth_dev*)pkt_dev; > rte_pkt_tx_burst(eth_dev, queue_id, tx_pkts, nb_pkts); > break; > #endif > > #ifdef RTE_LIBRTE_KNI > case RTE_PKT_DEV_KNI: > //... > break; > #endif > > default: > //Corrupted type or unsupported (without compiled > support) > //Ignore or fail(fatal error)? > break; > } > } > > //... Yes, this is an interesting approach, and with the inlining could indeed be less overhead for the ring and kni compared to my suggestion due to the inlining. There might be a slight overhead for the RX/TX ethdev functions though - 1/2 cycles due to the extra (hopefully predictable) branch in the RX/TX call, since we always need the indirect function call for the PMDs. I also like the use of pointers rather than port ids. Let me think on this a bit more. /Bruce