From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nipun.gupta@nxp.com>
Received: from EUR03-DB5-obe.outbound.protection.outlook.com
 (mail-eopbgr40052.outbound.protection.outlook.com [40.107.4.52])
 by dpdk.org (Postfix) with ESMTP id 92ACF377E
 for <dev@dpdk.org>; Mon, 24 Jul 2017 15:06:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; 
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=QptEu/DbbU8H6eTkOlDueLZZ+ccDJ1/cJMxbOFyXeGo=;
 b=IE8lRHxdtXFiD3l8q30nX1N9DFN/yFO3ZAGC78v+WgSaI5o19CLL1IK5ZhZ4WqgG5Sty9tJtjb/hhaHBe2DLPDoPZphZUnxC+cxjQ80HaEAnRkvZ6ZaLk39bbfxNwGDdjYGAMHBhIrVBZEOLzfVfqhQB3gH3GIvvHBaD6loYK/8=
Received: from HE1PR0401MB2425.eurprd04.prod.outlook.com (10.168.33.22) by
 DB4PR04MB0768.eurprd04.prod.outlook.com (10.141.45.21) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id
 15.1.1282.10; Mon, 24 Jul 2017 13:06:56 +0000
Received: from HE1PR0401MB2425.eurprd04.prod.outlook.com
 ([fe80::a06b:de0:6c53:1fc1]) by HE1PR0401MB2425.eurprd04.prod.outlook.com
 ([fe80::a06b:de0:6c53:1fc1%18]) with mapi id 15.01.1282.017; Mon, 24 Jul 2017
 13:06:54 +0000
From: Nipun Gupta <nipun.gupta@nxp.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>, "Rao, Nikhil"
 <nikhil.rao@intel.com>, "jerin.jacob@caviumnetworks.com"
 <jerin.jacob@caviumnetworks.com>
CC: "Eads, Gage" <gage.eads@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
 "thomas@monjalon.net" <thomas@monjalon.net>, "Richardson, Bruce"
 <bruce.richardson@intel.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
 "Vangati, Narender" <narender.vangati@intel.com>, "Gujjar, Abhinandan S"
 <abhinandan.gujjar@intel.com>
Thread-Topic: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
Thread-Index: AQHS9loW9CPBh9hook6mT2JxEF8VJqJihdpQgABdxgCAABJL0A==
Date: Mon, 24 Jul 2017 13:06:54 +0000
Message-ID: <HE1PR0401MB242560DA7249942F5F01EA9AE6BB0@HE1PR0401MB2425.eurprd04.prod.outlook.com>
References: <29140c16-909a-1b9a-7391-481f900bd13c@intel.com>
 <1499377952-5306-1-git-send-email-nikhil.rao@intel.com>
 <HE1PR0401MB24258D3722EB977BD4CEF973E6BB0@HE1PR0401MB2425.eurprd04.prod.outlook.com>
 <E923DB57A917B54B9182A2E928D00FA640C3F8FC@IRSMSX102.ger.corp.intel.com>
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA640C3F8FC@IRSMSX102.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is )
 smtp.mailfrom=nipun.gupta@nxp.com; 
x-originating-ip: [192.88.169.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB4PR04MB0768;
 7:1uGhqbDDHHVGxRJlw8A8WEegZk3cihSZLVHLC70HJuboT4LFxJ7ISBGl6jhcnlS7l9gEIaBwGBpcam9FGuGe4UF6GY77EWXFMtM3nYI9Df0URq+IsR0L4Rm+jtliaG0ppq6LrjVoNa2rY/BI8ib25H/ZvzBxf8zn6qEsbA3YeH3Y2gHJE0XzcS218LhweLyWx5e8Oh8sSjF44868zhxSDrUGXXg34YrhdxHDGj9zzIa2jPAILeWR3KLlDPIEVdHYub1IK5uN+nMKb043u4IRG/Oh1P84dDCMo+uYFWG0q8eM5wSKz2lChb9wzzIl+3kzUUK99LkLfeFmRHFZHhpPUppB+EX2vem/9DazghqgjjRIjeP5mDa3pwsYcsPa3QrmZ+f0re/6hhYqHpf0ijitWNySd9TZLtCW5aypPPKDrJ/8nh85hpYHwEEJk/0t6FKuopexIWQykJxJdNeCUYZNNXV+FO/abslnnZQa7wfZ0aayFGyK97KbL06uB5PaqkRt1yPihGenJrUDeVfvqIApiknVDHHgKXcEtMjrcWaxsZTT0PQK8ynHyq4J1yeZAimq8Fz+WBRqlLcoemh1PhHfmls/xCvavi6lJdQi9u2YQkCja0xcR+DzwrLbGv7XtyaGKcBpSKFMjU6ZoNBDEru6V0/IsFPhM01eQMCFEr4bsxaR3G38Ty9uUk+7qxBI53957TZXe3O/kx9BwV3AjNa7tJ+2dx2gJXgBsGPJQGfNztW32Q5ahzmhEC299xOTpbmDQ2Sb7WDrWM1Hv38MZ7rgXUFHTDxv/z5H55yz+A575TA=
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM;
 SFS:(10009020)(6009001)(39450400003)(39850400002)(39400400002)(39860400002)(39840400002)(39410400002)(199003)(53754006)(43544003)(189002)(377454003)(13464003)(55016002)(25786009)(229853002)(2950100002)(86362001)(8936002)(2900100001)(3660700001)(33656002)(6506006)(2906002)(7736002)(97736004)(3280700002)(53936002)(575784001)(6306002)(54906002)(6436002)(99286003)(9686003)(74316002)(81156014)(81166006)(4326008)(6246003)(53376002)(38730400002)(14454004)(66066001)(478600001)(54356999)(2501003)(76176999)(50986999)(7696004)(68736007)(5660300001)(102836003)(5250100002)(105586002)(106356001)(8676002)(101416001)(966005)(189998001)(305945005)(93886004)(3846002)(53546010)(6116002);
 DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR04MB0768;
 H:HE1PR0401MB2425.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;
 A:1; MX:1; LANG:en; 
x-ms-office365-filtering-correlation-id: dbd07bf6-e241-4629-5139-08d4d294db7b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
 RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);
 SRVR:DB4PR04MB0768; 
x-ms-traffictypediagnostic: DB4PR04MB0768:
x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197)(228905959029699); 
x-microsoft-antispam-prvs: <DB4PR04MB0768548E194AA0E6CB3E0E1BE6BB0@DB4PR04MB0768.eurprd04.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
 RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);
 SRVR:DB4PR04MB0768; BCL:0; PCL:0;
 RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);
 SRVR:DB4PR04MB0768; 
x-forefront-prvs: 0378F1E47A
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2017 13:06:54.3804 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR04MB0768
Subject: Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet
	Rx queues
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: Mon, 24 Jul 2017 13:06:57 -0000



> -----Original Message-----
> From: Van Haaren, Harry [mailto:harry.van.haaren@intel.com]
> Sent: Monday, July 24, 2017 16:03
> To: Nipun Gupta <nipun.gupta@nxp.com>; Rao, Nikhil <nikhil.rao@intel.com>=
;
> jerin.jacob@caviumnetworks.com
> Cc: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; Richardson, Bruce <bruce.richardson@intel.com>;
> Hemant Agrawal <hemant.agrawal@nxp.com>; Vangati, Narender
> <narender.vangati@intel.com>; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>
> Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queu=
es
>=20
> > From: Nipun Gupta [mailto:nipun.gupta@nxp.com]
> > Sent: Monday, July 24, 2017 11:11 AM
> > To: Rao, Nikhil <nikhil.rao@intel.com>; jerin.jacob@caviumnetworks.com
> > Cc: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org;
> thomas@monjalon.net; Richardson, Bruce
> > <bruce.richardson@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; Hemant
> > Agrawal <hemant.agrawal@nxp.com>; Vangati, Narender
> <narender.vangati@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>
> > Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx qu=
eues
> >
> > Hi Nikhil/Edas,
>=20
> Hi All,
>=20
> I'll reply on the service-cores topic, and leave the config to those more=
 involved
> and familiar with them than I :)
>=20
> > > -----Original Message-----
> > > From: Nikhil Rao [mailto:nikhil.rao@intel.com]
> > > Sent: Friday, July 07, 2017 3:23
> > > To: jerin.jacob@caviumnetworks.com
> > > Cc: gage.eads@intel.com; dev@dpdk.org; thomas@monjalon.net;
> > > bruce.richardson@intel.com; harry.van.haaren@intel.com; Hemant Agrawa=
l
> > > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>;
> > > narender.vangati@intel.com; Nikhil Rao <nikhil.rao@intel.com>;
> Abhinandan
> > > Gujjar <abhinandan.gujjar@intel.com>
> > > Subject: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queu=
es
> > >
> > > Eventdev-based networking applications require a component to dequeue
> > > packets from NIC Rx queues and inject them into eventdev queues[1]. W=
hile
> > > some platforms (e.g. Cavium Octeontx) do this operation in hardware, =
other
> > > platforms use software.
> > >
> > > This patchset introduces an ethernet Rx event adapter that dequeues p=
ackets
> > > from ethernet devices and enqueues them to event devices. It is based=
 on
> > > a previous RFC[2].
> > >
> > > The adapter is designed to work with the EAL service core[3]. If
> > > an application determines that the adapter is required, it can regist=
er and
> > > launch it on a service core. Alternatively, this adapter can serve as=
 a
> > > template for applications to design customer ethernet Rx event adapte=
rs
> > > better suited to their needs.
> > >
> > > The adapter can service multiple ethernet devices and queues. Each qu=
eue is
> > > configured with a servicing weight to control the relative frequency =
with
> > > which the adapter polls the queue, and the event fields to use when
> > > constructing packet events. The adapter has two modes for programming=
 an
> > > event's flow ID: use a static per-queue user-specified value or use t=
he RSS
> > > hash.
> > >
> > > A detailed description of the adapter is contained in the header's
> > > comments.
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2017-May/065341.html
> > > [2] http://dpdk.org/ml/archives/dev/2017-May/065539.html
> > > [3] http://dpdk.org/ml/archives/dev/2017-July/069782.html
> > >
> > > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > ---
> > >
> > > v2:
> > > Thanks Jerin for review - below is a list of changes you
> > > suggested.
> > >
> > > - all public symbols are started with rte_event_.
> > > - Add Doxygen reference with @see.
> > > - Mention setting of ev.event_type.
> > > - Mention adapter to service function mapping.
> > > - Remove rte_eth_rx_event_adapter_dev_add/del().
> > > - Change rx_queuee_id to int32_t and use -1 to denote all Rx queues.
> > > - Add rte_eth_event_rx_queue_del().
> > >
> > > Other changes
> > > - Remove adapter's run function (rte_event_eth_rx_adapter_run()) from
> > >   the public interface. The adapter internally uses it to create a
> > >   service.
> > > - Add a blocked cycle count to stats. Further description is containe=
d
> > >   in the header.
> > > - Minor struct renames rte_event_eth_rx_adapter_config -> .._conf
> > > ---
> > >  lib/librte_eventdev/rte_event_eth_rx_adapter.h | 301 +++++++++
> > >  lib/librte_eventdev/rte_event_eth_rx_adapter.c | 825
> > > +++++++++++++++++++++++++
> > >  lib/librte_eventdev/rte_eventdev_version.map   |  13 +
> > >  lib/Makefile                                   |   2 +-
> > >  lib/librte_eventdev/Makefile                   |   2 +
> > >  5 files changed, 1142 insertions(+), 1 deletion(-)
> > >  create mode 100644 lib/librte_eventdev/rte_event_eth_rx_adapter.h
> > >  create mode 100644 lib/librte_eventdev/rte_event_eth_rx_adapter.c
> > >
> > > diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.h
> > > b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
> > > new file mode 100644
> > > index 000000000..5ccd0bd24
> > > --- /dev/null
> > > +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.h
> > > @@ -0,0 +1,301 @@
> > > +/*
> > > + *   Copyright(c) 2017 Intel Corporation. All rights reserved.
> > > + *   All rights reserved.
> > > + *
> > > + *   Redistribution and use in source and binary forms, with or with=
out
> > > + *   modification, are permitted provided that the following conditi=
ons
> > > + *   are met:
> > > + *
> > > + *     * Redistributions of source code must retain the above copyri=
ght
> > > + *       notice, this list of conditions and the following disclaime=
r.
> > > + *     * Redistributions in binary form must reproduce the above cop=
yright
> > > + *       notice, this list of conditions and the following disclaime=
r in
> > > + *       the documentation and/or other materials provided with the
> > > + *       distribution.
> > > + *     * Neither the name of Intel Corporation nor the names of its
> > > + *       contributors may be used to endorse or promote products der=
ived
> > > + *       from this software without specific prior written permissio=
n.
> > > + *
> > > + *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> > > CONTRIBUTORS
> > > + *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> > > + *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> > > FITNESS FOR
> > > + *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> > > COPYRIGHT
> > > + *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> > > INCIDENTAL,
> > > + *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> BUT
> > > NOT
> > > + *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
> LOSS
> > > OF USE,
> > > + *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND
> > > ON ANY
> > > + *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> > > TORT
> > > + *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> OF
> > > THE USE
> > > + *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> > > DAMAGE.
> > > + */
> > > +
> > > +#ifndef _RTE_EVENT_ETH_RX_ADAPTER_
> > > +#define _RTE_EVENT_ETH_RX_ADAPTER_
> > > +
> > > +/**
> > > + * @file
> > > + *
> > > + * RTE Event Ethernet Rx Adapter
> > > + *
> > > + * An eventdev-based packet processing application enqueues/dequeues
> mbufs
> > > + * to/from the event device. The ethernet Rx event adapter's role is=
 to
> transfer
> > > + * mbufs from the ethernet receive queues managed by DPDK to an even=
t
> > > device.
> > > + * The application uses the adapter APIs to configure the packet flo=
w
> between
> > > + * the ethernet devices and event devices. The adapter is designed t=
o work
> with
> > > + * the EAL service cores. The adapter's work can be parallelized by =
dividing
> the
> > > + * NIC Rx queues among multiple adapter services that run in paralle=
l.
> >
> > First of all, apologies for commenting late on this. I am going through=
 this
> patchset and
> > have some concerns over this.
> > It is mentioned that "The adapter is designed to work with * the EAL se=
rvice
> cores"
> > Does this mean that the adapter cannot function without service core?
> > In the case where Ethdev HW is capable of injecting the packet to compa=
tible
> HW eventdev
> > driver, there is no service
> > required. It seems this patchset does not take care of this use-case or=
 maybe I
> am missing
> > something here?
>=20
>=20
> The "service cores" is a method of abstracting lcore requirements. In sho=
rt, with
> a SW PMD, a service core is required to perform the event scheduling. Wit=
h the
> HW use case as you describe, no core is required. So in the HW case, no s=
ervice
> cores are allocated in DPDK, and as a result, all your cores are availabl=
e to the
> application.
>=20
> If I understand correctly, the generic "Event Ethernet RX Adapter" will r=
egister a
> service which needs to be run (by a service core) in order to perform SW =
polling
> of the NIC, and enqueue to the eventdev.
>=20
> In order to support the hardware use-case, no service is registered and n=
o
> service lcores required. The HW is allowed to perform the Ethdev -> Event=
dev
> enqueue.
>=20
> Hope that makes sense! -Harry

With function pointer based approach the adapter calls will be propagated t=
o eventdev PMD so
here won't this way the event driver will be responsible for registering th=
e service? I don't think the
generic 'Event ethernet Rx adapter' would register a service with this mode=
l.

Thanks,
Nipun