From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0DF2B37B0 for ; Fri, 5 May 2017 21:03:02 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 May 2017 12:03:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,293,1491289200"; d="scan'208";a="257475209" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 05 May 2017 12:02:59 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.101]) by FMSMSX105.amr.corp.intel.com ([169.254.4.61]) with mapi id 14.03.0319.002; Fri, 5 May 2017 12:02:59 -0700 From: "Eads, Gage" To: Jerin Jacob , "dev@dpdk.org" CC: "thomas@monjalon.net" , "Richardson, Bruce" , "Van Haaren, Harry" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Vangati, Narender" Thread-Topic: [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to inject packets Thread-Index: AQHSxaRXEEceKwbbnkaJ7g4lFmh3naHmAoDw Date: Fri, 5 May 2017 19:02:59 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E01EA8327@FMSMSX108.amr.corp.intel.com> References: <20170505133341.31138-1-jerin.jacob@caviumnetworks.com> In-Reply-To: <20170505133341.31138-1-jerin.jacob@caviumnetworks.com> 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] eventdev: abstract ethdev HW capability to inject packets 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: Fri, 05 May 2017 19:03:03 -0000 Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Friday, May 5, 2017 8:34 AM > To: dev@dpdk.org > Cc: thomas@monjalon.net; Richardson, Bruce ; > Van Haaren, Harry ; hemant.agrawal@nxp.com; > Eads, Gage ; nipun.gupta@nxp.com; Vangati, > Narender ; Jerin Jacob > > Subject: [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to i= nject > packets > =20 > Some Ethdev Hardware is capable of injecting the events(Ethernet packets= ) to > eventdev without the need for dedicated service cores on Rx path. > Since eventdev API is device capability agnostic, we need to address thr= ee > combinations of ethdev and eventdev PMD drivers. > =20 > 1) Ethdev HW is not capable of injecting the packets and SW eventdev dri= ver(All > existing ethdev PMD + drivers/event/sw PMD combination) > 2) Ethdev HW is not capable of injecting the packets and not compatible = HW > eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD > combination) > 3) Ethdev HW is capable of injecting the packet to compatible HW eventde= v > driver. > =20 > This patch abstract such capability disparity and have unified way to ge= t the > functionality in the application. > =20 > NOTE: The same infrastructure can be used _if_ an SW PMD wish to create = the > default producer as service function with the service core scheme in EAL= to > make it completely transparent to the application for the default case. = The > selection of service core enablement can be a vdev argument to SW PMD. > =20 I'm not sure that a vdev argument/arguments is the right way to go for case= s 1 and 2. It'll be rather complicated to specify the service core configur= ation per event producer on the command line, and that configuration can't = use runtime information. What do you think about this approach: We develop a library of device produ= cer code, with interfaces designed to run on service cores, that the app ca= n run if rte_event_dev_has_producer() returns FALSE. The device producer co= de would, at minimum, have some configuration function (more or less equiva= lent to the rte_event_queue_producer_conf) and a run function that (at a hi= gh level) processes eth/crypto/etc.-dev queues and injects events into an e= vent device. For example, if rte_event_dev_has_producer() indicates there's no hardware = support for connecting an ethdev to the event device, the application confi= gures the ethdev->eventdev producer code and installs the run function with= the service core infrastructure. Plus, this approach allows an application to plug in their own device produ= cer logic, if they require some app-specific functionality. In that case, t= he DPDK-provided device producer could serve as a template for the app deve= loper. If you agree this approach -- at least at a high level -- I'll put together= an RFC the library and a header file for an eth->eventdev block and we can= work on the details. > Detailed comments are added in the header file. > =20 > Example API usage: > =20 > - rte_eth_dev_configure(port,..); > - rte_eth_rx_queue_setup(port,..); > - rte_eth_dev_start(port,..); > =20 > struct rte_event_queue_producer_conf ethdev_conf =3D { > .event_type =3D RTE_EVENT_TYPE_ETHDEV; > .sched_type =3D RTE_SCHED_TYPE_ATOMIC; > .priority =3D RTE_EVENT_DEV_PRIORITY_LOWEST; > .ethdev.ethdev_port =3D port; > .ethdev.rx_queue_id =3D -1; > }; > =20 > - rte_event_dev_has_producer(dev_id, ðdev_conf); # configure addition= al > producer ports based on eventdev producer capability. > - rte_event_dev_configure(dev_id,..); > =20 > struct rte_event_queue_conf =3D conf { > nb_producers =3D 1; > producers =3D ðdev_conf; > }; > # configure event queue based on eventdev producer capability > - rte_event_queue_setup(dev_id, &conf,..); > - rte_event_port_setup(dev_id,..); > - rte_event_dev_start(dev_id); > =20 > Signed-off-by: Jerin Jacob > --- > This patch is based on the review commets from following RFC > http://dpdk.org/ml/archives/dev/2017-May/065176.html > --- > lib/librte_eventdev/rte_eventdev.h | 110 > +++++++++++++++++++++++++++++++++++++ > 1 file changed, 110 insertions(+) > =20 > diff --git a/lib/librte_eventdev/rte_eventdev.h > b/lib/librte_eventdev/rte_eventdev.h > index 20e7293e0..202d03f61 100644 > --- a/lib/librte_eventdev/rte_eventdev.h > +++ b/lib/librte_eventdev/rte_eventdev.h > @@ -396,6 +396,100 @@ struct rte_event_dev_info { int > rte_event_dev_info_get(uint8_t dev_id, struct rte_event_dev_info *dev_in= fo); > =20 > +/** Eventdev producer configuration structure. > + * The events are injected to event device through *enqueue* operation > +with > + * op =3D=3D RTE_EVENT_OP_NEW by event producers in the system. If the > +event > + * producer is an Ethernet device then eventdev PMD may operate in > +conjunction > + * with ethdev PMD to injects the events(Ethernet packets) to eventdev. > + * The event injection can happen in HW or SW or the combination of > +these two > + * based on the HW capabilities of target eventdev and ethdev PMDs. > + * > + * @see rte_event_dev_has_producer() rte_event_queue_setup() > + * > + */ > +struct rte_event_dev_producer_conf { > + uint32_t event_type:4; > + /**< Event type to classify the event source. > + * @see RTE_EVENT_TYPE_ETHDEV, (RTE_EVENT_TYPE_*) > + */ > + uint8_t sched_type:2; > + /**< Scheduler synchronization type (RTE_SCHED_TYPE_*) > + * associated with flow id on a given event queue for the enqueue > + * operation. > + */ > + uint8_t priority; > + /**< Event priority relative to other events in the > + * event queue. The requested priority should in the > + * range of [RTE_EVENT_DEV_PRIORITY_HIGHEST, > + * RTE_EVENT_DEV_PRIORITY_LOWEST]. > + * The implementation shall normalize the requested > + * priority to supported priority value. > + * Valid when the device has > + * RTE_EVENT_DEV_CAP_EVENT_QOS capability. > + */ > + union { > + struct rte_event_ethdev_producer { > + uint16_t ethdev_port; > + /**< The port identifier of the Ethernet device */ > + int32_t rx_queue_id; > + /**< The index of the receive queue from which to > + * retrieve the input packets and inject to eventdev. > + * The value -1 denotes all the Rx queues configured > + * for the given ethdev_port are selected for retrieving > + * the input packets and then injecting the > + * events/packets to eventdev. > + * The rte_eth_rx_burst() result is undefined > + * if application invokes on bounded ethdev_port and > + * rx_queue_id. > + */ > + } ethdev; /* RTE_EVENT_TYPE_ETHDEV */ > + /**< Valid when event_type =3D=3D RTE_EVENT_TYPE_ETHDEV. > + * Implementation may use mbuff's rss->hash value as > + * flow_id for the enqueue operation. > + */ > + }; > +}; > + > +/** > + * Check for eventdev producer capability for the given eventdev > +producer *conf* > + * on an event device. > + * > + * When application needs to setup an event producer to inject the > +events to > + * eventdev, application must check the event device producer > +capability by > + * invoking this function, On success, application can configure to > +inject the > + * events to eventdev by setting up the event queue using > + * rte_event_queue_setup() with checked *conf*. > + * On failure due to lack of adequate capability in PMD or an > +application that > + * wish to inject the event through application, it must create > +additional > + * event port by configuring the eventdev with rte_event_dev_config() > +and use > + * rte_event_enqueue_burst() to inject the event through > + * op =3D=3D RTE_EVENT_OP_NEW operation. > + * > + * @param dev_id > + * The identifier of the device. > + * @param conf > + * The eventdev producer configuration structure. > + * > + * @see rte_event_queue_setup() rte_event_dev_config() > + * > + * @return > + * - TRUE (value different than 0) if the eventdev is capable of prod= ucing the > + * events for the given *conf* > + * - FALSE (value zero) if the eventdev is not capable of producing t= he events > + * for the given *conf* > + * > + * PMD may have partial support for the requested capability. > + * On return FALSE, PMD sets rte_errno to reflect the partial support= . > + * Possible rte_errno values include: > + * - -EOPNOTSUPP: The eventdev is not capable of pulling the events f= rom > + * the specific producer queue. On this errno, The caller may try to > + * check the capability with rx_queue_id as -1 in *conf*. How do we indicate the PMD has zero support? E.g., return FALSE and set rte= _errno to 0? > + * > + */ > +int > +rte_event_dev_has_producer(uint8_t dev_id, > + struct rte_event_dev_producer_conf *conf); I interpret this to mean the user queries the presence of a particular type= of producer by setting conf->event_type. Is that correct? For an ethdev producer, I assume the PMD's response would depend on conf->e= thdev_port -- that is, it could return true for a hardware ethdev and but w= ould always return false for a software (e.g. pcap) ethdev. Thanks, Gage