From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gage.eads@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by dpdk.org (Postfix) with ESMTP id 0DF2B37B0
for <dev@dpdk.org>; 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" <gage.eads@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: "thomas@monjalon.net" <thomas@monjalon.net>, "Richardson, Bruce"
<bruce.richardson@intel.com>, "Van Haaren, Harry"
<harry.van.haaren@intel.com>, "hemant.agrawal@nxp.com"
<hemant.agrawal@nxp.com>, "nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"Vangati, Narender" <narender.vangati@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <bruce.richardson@intel.com>;
> Van Haaren, Harry <harry.van.haaren@intel.com>; hemant.agrawal@nxp.com;
> Eads, Gage <gage.eads@intel.com>; nipun.gupta@nxp.com; Vangati,
> Narender <narender.vangati@intel.com>; Jerin Jacob
> <jerin.jacob@caviumnetworks.com>
> 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 <jerin.jacob@caviumnetworks.com>
> ---
> 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