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 11EDB37A2 for ; Tue, 2 May 2017 18:25:01 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 09:25:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,280,1491289200"; d="scan'208";a="1142716969" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga001.fm.intel.com with ESMTP; 02 May 2017 09:24:59 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX108.ger.corp.intel.com (163.33.3.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 2 May 2017 17:24:58 +0100 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.153]) by irsmsx155.ger.corp.intel.com ([169.254.14.202]) with mapi id 14.03.0319.002; Tue, 2 May 2017 17:24:57 +0100 From: "Van Haaren, Harry" To: Jerin Jacob , "Eads, Gage" CC: "dev@dpdk.org" , "Richardson, Bruce" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Vangati, Narender" Thread-Topic: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to inject packets to eventdev Thread-Index: AQHSuEcJap/01seQ00uQC3rC4ShC+KHQXNMAgBDcXICAABLBkA== Date: Tue, 2 May 2017 16:24:57 +0000 Message-ID: References: <20170418132307.1888-1-jerin.jacob@caviumnetworks.com> <9184057F7FC11744A2107296B6B8EB1E01EA280D@FMSMSX108.amr.corp.intel.com> <20170502155920.GA2664@jerin> In-Reply-To: <20170502155920.GA2664@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDA5ZDkwM2EtYzYxNi00N2RhLWJmNzMtZDE4YzU2NmEwZGY5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkczaXBMUGpBbStYMVhpMkVkNUFGZXdnODlrNGRKcVcxd1NyUFRLdlNiZEE9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] [PATCH] eventdev: abstract ethdev HW capability to inject packets to eventdev X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 16:25:02 -0000 Some comments inline with [HvH] prefix > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Tuesday, May 2, 2017 5:01 PM > To: Eads, Gage > Cc: dev@dpdk.org; Richardson, Bruce ; Van Haa= ren, Harry > ; hemant.agrawal@nxp.com; nipun.gupta@nxp.com= ; Vangati, Narender > > Subject: Re: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capabi= lity to inject packets > to eventdev >=20 > -----Original Message----- > > Date: Fri, 21 Apr 2017 22:31:52 +0000 > > From: "Eads, Gage" > > To: Jerin Jacob , "dev@dpdk.org" > > > > CC: "Richardson, Bruce" , "Van Haaren, Harr= y" > > , "hemant.agrawal@nxp.com" > > , "nipun.gupta@nxp.com" , > > "Vangati, Narender" > > Subject: RE: [RFC] [dpdk-dev] [PATCH] eventdev: abstract ethdev HW > > capability to inject packets to eventdev > > > > Hi Jerin, >=20 > Hi Gage, >=20 > > > > Thanks for getting this ball rolling, and I agree that we need a soluti= on that covers the > three cases you described. >=20 > OK. Half problem is solved if we agree on problem statement :-) [HvH] +2 :) > > We've also been thinking about an environment where devices (NIC Rx (or= even Tx), crypto, or > a timer "device" that uses librte_timer to inject events) can plug in eve= ntdev -- whether > through a direct connection to the event scheduler (case #3) or using sof= tware to bridge the > gap -- such that application software can have a consistent view of devic= e interfacing on > different platforms. >=20 > Make sense. Yes, The NPUs can produce events from NIC Rx, NIC Tx, crypto,= timer device > sources without SW service functions. >=20 > > > > Some initial thoughts on your proposal: > > > > 1. I imagine that deploying these service functions at the granularity = of a core can be > excessive on devices with few (<=3D 8) cores. For example, if the crypto = traffic rate is low then > a cryptodev service function could be co-scheduled with other service fun= ctions and/or > application work. I think we'll need a more flexible deployment of these = service functions. >=20 > I agree. >=20 > > > > 2. Knowing which device type a service function is for would be useful = -- without it, it's > not possible to assign the function to the NUMA node on which the device = is located. >=20 > I guess we can use rte_eth_dev_socket_id() on requested port to get NUMA > id. >=20 > > > > 3. Placing the service core logic in the PMDs is nice in terms of appli= cation ease-of-use, > but it forces PMD to write one-size-fits-all service core functions, wher= e, for example, the > application's control of the NIC Rx functionality is limited to the optio= ns that struct > rte_event_queue_producer_conf exports. An application may want customized= service core behavior > such as: prioritized polling of Rx queues, using Rx queue interrupts for = low traffic rate > queues, or (for "closed system" eventdevs) control over whether/when a se= rvice core drops > events (and a way to notify applications of event drops). For such cases,= I think the > appropriate solution is allow applications to plug in their own service c= ore functions (when > hardware support isn't present). >=20 > I agree. I think, we can have reusable producer code as static inline > functions in librte_event with multiple event producing strategies and > let application to call respective one if HW support is not present or > not adequate. >=20 > I will work towards this theme in RFC v2. [HvH] Yes agree. I'd like to suggest that there might be two issues we're solving= at the same time, A) How to "grab" cores for a generic software fallback p= urpose, and B) how we can enable the various eth/event/crypto-dev component= s to "play nice" For A), I have a header file that I'd like to share as an RFC on allowing = EAL to manage this requesting of cores. The RFC does not deal with B) and c= onfiguration of eth/event/crypto devs. > > Some of these thoughts are reflected in the eventdev_pipeline app[1] th= at Harry submitted > earlier today, like flexible service function deployment. In that app, th= e user supplies a > device coremask that can pin a service function to a core, multiplex mult= iple functions on the > core, or even affinitize the service function to multiple cores (using cm= pset-based exclusion > to ensure it's executed by one lcore at a time). >=20 > Thanks for the sample application.I could make it work with NIC + HW > eventdev with some tweaking. I will send the review comment on that > email thread. [HvH] Great! > One thing, I noticed with cmpset based scheme is that, at given point of > time it can produce at most up to the events one LCORE can support.May no= t > be well suited for low end cores.I think, we need multiple event > producer strategy code as common code. > > > In thinking about this, Narender and I have envisioned something like a= framework for > eventdev applications in which these service functions can be registered = and (in a similar > manner to eventdev_pipeline's service functions) executed. >=20 > That will be useful. I think it will be not just restricted to eventdev > applications, I guess, New traffic manager's SW implementation or any > future offloads need a framework for service function registration and > invocation. [HvH] Yes, the proposal for A) above would be mostly EAL based, providing a gener= ic "service core" API to DPDK components that require an lcore for "interna= l" tasks (e.g.: Eventdev SW PMD). I'll get the RFC up ASAP with you guys on CC, -Harry