From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 34989282 for ; Wed, 10 May 2017 22:16:44 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP; 10 May 2017 13:16:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,320,1491289200"; d="scan'208";a="99921007" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga005.fm.intel.com with ESMTP; 10 May 2017 13:16:43 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 10 May 2017 13:16:43 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.101]) by FMSMSX153.amr.corp.intel.com ([169.254.9.224]) with mapi id 14.03.0319.002; Wed, 10 May 2017 13:16:42 -0700 From: "Eads, Gage" To: Jerin Jacob , "Van Haaren, Harry" CC: "dev@dpdk.org" , "Richardson, Bruce" Thread-Topic: [PATCH 1/3] examples/eventdev_pipeline: added sample app Thread-Index: AQHSuoT4lPyaEinzVE2vpzMKMFa/oqHuLyaA//+pycCAAEUMkA== Date: Wed, 10 May 2017 20:16:42 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E01EA9A3E@FMSMSX108.amr.corp.intel.com> References: <1492768299-84016-1-git-send-email-harry.van.haaren@intel.com> <1492768299-84016-2-git-send-email-harry.van.haaren@intel.com> <20170510141202.GA8431@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added sample app 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: Wed, 10 May 2017 20:16:45 -0000 > -----Original Message----- > From: Eads, Gage > Sent: Wednesday, May 10, 2017 11:41 AM > To: 'Jerin Jacob' ; Van Haaren, Harry > > Cc: dev@dpdk.org; Richardson, Bruce > Subject: RE: [PATCH 1/3] examples/eventdev_pipeline: added sample app > =20 > =20 > =20 > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Wednesday, May 10, 2017 9:12 AM > > To: Van Haaren, Harry > > Cc: dev@dpdk.org; Eads, Gage ; Richardson, Bruce > > > > Subject: Re: [PATCH 1/3] examples/eventdev_pipeline: added sample app > > > > -----Original Message----- > > > Date: Fri, 21 Apr 2017 10:51:37 +0100 > From: Harry van Haaren > > > To: dev@dpdk.org > CC: > > jerin.jacob@caviumnetworks.com, Harry van Haaren > > > , Gage Eads , Bruce > > > Richardson > Subject: [PATCH 1/3] > > examples/eventdev_pipeline: added sample app > X-Mailer: > > git-send-email 2.7.4 > > This commit adds a sample app for the > > eventdev library. > > > The app has been tested with DPDK 17.05-rc2, hence this release (or > > > later) is recommended. > > > > =20 > > =20 > > > > > + ev[i].op =3D RTE_EVENT_OP_NEW; > > > + ev[i].sched_type =3D queue_type; > > > > The value of RTE_EVENT_QUEUE_CFG_ORDERED_ONLY !=3D > > RTE_SCHED_TYPE_ORDERED. So, we cannot assign .sched_type as > > queue_type. > > > > I think, one option could be to avoid translation in application is > > to > > - Remove RTE_EVENT_QUEUE_CFG_ALL_TYPES, > RTE_EVENT_QUEUE_CFG_*_ONLY > > - Introduce a new RTE_EVENT_DEV_CAP_ to denote > > RTE_EVENT_QUEUE_CFG_ALL_TYPES cap ability > > - add sched_type in struct rte_event_queue_conf. If capability flag i= s > > not set then implementation takes sched_type value for the queue. > > > > Any thoughts? > =20 > I'm not sure this change is needed. We could create a sched_type[] array= , > indexed by queue ID, for assigning the event's sched type. > =20 > With the proposed approach, the sched_type assignment would still be nee= ded > for "all types"-capable PMDs, so I'm not sure it buys us anything in the > application. > =20 > > > > > > > + ev[i].queue_id =3D qid; > > > + ev[i].event_type =3D RTE_EVENT_TYPE_CPU; > > > > IMO, RTE_EVENT_TYPE_ETHERNET is the better option here as it is > > producing the Ethernet packets/events. > > > > > + ev[i].sub_event_type =3D 0; > > > + ev[i].priority =3D RTE_EVENT_DEV_PRIORITY_NORMAL; > > > + ev[i].mbuf =3D mbufs[i]; > > > + RTE_SET_USED(prio_idx); > > > + } > > > + > > > + const int nb_tx =3D rte_event_enqueue_burst(dev_id, port_id, ev, > > > +nb_rx); > > > > For producer pattern i.e a burst of RTE_EVENT_OP_NEW, OcteonTX can do > > burst operation unlike FORWARD case(which is one event at a > > time).Earlier, I thought I can abstract the producer pattern in PMD, > > but it looks like we are going with application driven producer model > > based on latest RFC.So I think, we can add one flag to > > rte_event_enqueue_burst to denote all the events are of type > RTE_EVENT_OP_NEW as hint.SW driver can ignore this. > > > > I can send a patch for the same. > > > > Any thoughts? > > > =20 > Makes sense, though I'm a little hesitant about putting this sort of PMD= -specific > hint in the enqueue API. Perhaps we can use the impl_opaque field, or ha= ve the > PMD inspect the event_type (if TYPE_ETHDEV, assume all packets in the bu= rst > are NEWs)? > =20 Another idea -- what if the enqueue burst argument had these four values: M= ixed, all RTE_EVENT_OP_NEW, all RTE_EVENT_OP_FWD, all RTE_EVENT_OP_RELEASE? In the "all _" cases, the app doesn't need to set the event's op field and = the PMD can potentially optimize for that type of operation. In the "mixed" case the PMD would inspect each event's op field and handle = them accordingly.