From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gage.eads@intel.com>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id 09B3028C3
for <dev@dpdk.org>; Wed, 9 Aug 2017 21:24:32 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
by fmsmga105.fm.intel.com with ESMTP; 09 Aug 2017 12:24:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.41,348,1498546800"; d="scan'208";a="888317113"
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206])
by FMSMGA003.fm.intel.com with ESMTP; 09 Aug 2017 12:24:31 -0700
Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by
FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS)
id 14.3.319.2; Wed, 9 Aug 2017 12:24:31 -0700
Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.208]) by
FMSMSX154.amr.corp.intel.com ([169.254.6.211]) with mapi id 14.03.0319.002;
Wed, 9 Aug 2017 12:24:31 -0700
From: "Eads, Gage" <gage.eads@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
CC: "Rao, Nikhil" <nikhil.rao@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
"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>, "Gujjar, Abhinandan S"
<abhinandan.gujjar@intel.com>
Thread-Topic: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
Thread-Index: AQHS+UPHG57s3lsJOEGnOtNDEbj1IKJNVPuAgAQ9jgCAAQCMgIAVfkqAgANrvwCABElYAIAAhsAAgAICaceACSSv0IABZSWA//+yYdA=
Date: Wed, 9 Aug 2017 19:24:30 +0000
Message-ID: <9184057F7FC11744A2107296B6B8EB1E01F0EEF4@FMSMSX108.amr.corp.intel.com>
References: <20170710104126.GA13609@jerin>
<4197b5f1-9a15-5892-12d2-6bd142bc4d85@intel.com>
<20170713184445.GA3659@jerin>
<123ed8d6-4fd9-8bee-d86e-d270a092169e@intel.com>
<20170729151252.GA25166@jerin>
<7b9ca757-f428-3675-b997-794ec6e96f2a@intel.com>
<20170801164242.GA6467@jerin>
<9184057F7FC11744A2107296B6B8EB1E01F00701@FMSMSX108.amr.corp.intel.com>
<20170803062315.GA14704@jerin>
<9184057F7FC11744A2107296B6B8EB1E01F030FC@FMSMSX108.amr.corp.intel.com>
<20170809161946.GA6650@jerin>
In-Reply-To: <20170809161946.GA6650@jerin>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzExYjU3ZGYtZDk0Ni00OWExLTg2MGEtOGY4MzFhYTBhNGEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNi41LjkuMyIsIlRydXN0ZWRMYWJlbEhhc2giOiI4ZDB6eUR3Z3pVVG9zZmJMeU1MbmJ2TTBHVXI1R1NmVHo2c0xWU2NzZjZrPSJ9
x-ctpclassification: CTP_PUBLIC
dlp-product: dlpe-windows
dlp-version: 10.0.102.7
dlp-reaction: no-action
x-originating-ip: [10.1.200.108]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 09 Aug 2017 19:24:33 -0000
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Wednesday, August 9, 2017 11:20 AM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: Rao, Nikhil <nikhil.rao@intel.com>; dev@dpdk.org; thomas@monjalon.net=
;
> Richardson, Bruce <bruce.richardson@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; hemant.agrawal@nxp.com;
> nipun.gupta@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
> -----Original Message-----
> > Date: Wed, 9 Aug 2017 02:23:15 +0000
> > From: "Eads, Gage" <gage.eads@intel.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > CC: "Rao, Nikhil" <nikhil.rao@intel.com>, "dev@dpdk.org"
> > <dev@dpdk.org>, "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>, "Gujjar, Abhinandan S"
> > <abhinandan.gujjar@intel.com>
> > Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet Rx
> > queues
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > Sent: Thursday, August 3, 2017 1:23 AM
> > > To: Eads, Gage <gage.eads@intel.com>
> > > Cc: Rao, Nikhil <nikhil.rao@intel.com>; dev@dpdk.org;
> > > thomas@monjalon.net; Richardson, Bruce <bruce.richardson@intel.com>;
> > > Van Haaren, Harry <harry.van.haaren@intel.com>;
> > > hemant.agrawal@nxp.com; nipun.gupta@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
> > > queues
> > >
> > > -----Original Message-----
> > > > Date: Wed, 2 Aug 2017 19:19:32 +0000
> > > > From: "Eads, Gage" <gage.eads@intel.com>
> > > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Rao, Nikhil"
> > > > <nikhil.rao@intel.com>
> > > > CC: "dev@dpdk.org" <dev@dpdk.org>, "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>, "Gujjar, Abhinandan S"
> > > > <abhinandan.gujjar@intel.com>
> > > > Subject: RE: [PATCH 1/2] eventdev: add event adapter for ethernet
> > > > Rx queues
> > > >
> > > >
> > > > <snip>
> > > >
> > > > > > >
> > > > > > > 5) specifying rte_event_eth_rx_adapter_conf.rx_event_port_id
> > > > > > > on
> > > > > > > rte_event_eth_rx_adapter_create() would waste one HW
> > > > > > > eventdev port if its happen to be used
> > > > > > > RX_ADAPTER_CAP_INBUILT_PORT on
> > > > > rte_event_eth_rx_adapter_queue_add().
> > > > > > > unlike SW eventdev port, HW eventdev ports are costly so I
> > > > > > > think, We need to have another eventdev PMD ops to create
> > > service/producer ports.
> > > > > > > Or any other scheme that creates
> > > > > > > rte_event_eth_rx_adapter_conf.rx_event_port_id
> > > > > > > on demand by common code.
> > > > > > >
> > > > > >
> > > > > > One solution is:
> > > > > >
> > > > > > struct rte_event_eth_rx_adapter_conf {
> > > > > > uint8_t dev_id;
> > > > > >
> > > > > > int (*conf_cb)(uint8_t id, uint8_t port_id, uint32_t
> > > > > > flags, struct rte_event_eth_rx_adapter_conf *conf);
> > > > > >
> > > > > > unsigned int max_nb_rx;
> > > > > >
> > > > > > int event_port_id;
> > > > > >
> > > > > > char service_name[];
> > > > > > }
> > > > > >
> > > > > > Where dev_id and conf_cb have to be specified in the create
> > > > > > call, but event_port_id and service_name will be filled in
> > > > > > when
> > > > > > conf_cb() is invoked
> > > > >
> > > > > I was thinking like event_port_id will be rte_event_port_count() =
+ 1.
> > > > > ie When adapter needs the additional port, It can
> > > > > - stop the eventdev
> > > > > - reconfigure with rte_event_queue_count() ,
> > > > > rte_event_port_count()
> > > > > + 1
> > > > > - start the eventdev.
> > > > >
> > > > > The only problem with callback is that all the application needs
> > > > > to implement
> > > it.
> > > > > If you think, application need more control then we can expose
> > > > > callback and if it is NULL then default handler can be called in =
common
> code.
> > > > >
> > > >
> > > > I don't think we can rely on there being another port available --
> > > > a user may
> > > have configured the sw eventdev with all 64 ports, for instance.
> > >
> > > On that case, irrespective any scheme(callback vs non callback) the
> > > adapter creation would fail. Right?
> > >
> > > > What if the user is required to calculate cfg.nb_event_ports as a
> > > > function of
> > > the RX_ADAPTER_CAP_INBUILT_PORT capability (i.e. add a port if the
> > > capability is not set), such that a reconfigure is not required?
> > >
> > > We have only one NON INBUILT eventdev port per adapter. Right? i.e
> > > in the v1 spec it was rte_event_eth_rx_adapter_conf.event_port_id,
> > > How about it can be rte_event_port_count() + 1 ? Since we are NOT
> > > linking this port, the context call be kept in adapter itself. Right?
> >
> > It could be. Thinking on it some more, I'm a little concerned about doi=
ng
> configuration without the application's knowledge. Possible issues that c=
ould
> arise:
> > - The user later reconfigures the event device with fewer ports and
> > the adapter's port becomes invalid, or reconfigures it with more ports
> > and begins using the port the adapter is using
> > - rte_event_port_count() + 1 extends beyond the PMD's capabilities
> > (the sw PMD is hard-coded to support a max of 64 ports, for example)
> >
> > Having the user be responsible for the port configuration could avoid t=
hese
> problems. Since the user needs to check the <eventdev, ethdev> pair's
> capabilities for the CAP_ADD_QUEUE anyway, they could also check for
> INBUILT_PORT and decide whether or not to request an additional port at
> eventdev configure time -- thereby ensuring they don't waste a port when =
using
> hardware with inbuilt ports. And this keeps the configuration code in one=
place
> (the app), rather than spread across the app, adapter, and potentially th=
e
> conf_cb.
>=20
> OK.Sounds reasonable.May be we can push the responsibility to application=
.We
> could have a helper function using the proposed adapter API. That helper
> function would create the adapter based on the capability for the _defaul=
t_
> case.
> Applications free to use the raw adapter API to get more control if requi=
red.
> Otherwise we will duplicate the code in all the applications.
>
Makes sense. Are you thinking the helper function would do stop + reconfig =
with additional port + start + setup port, or just setup the port with an I=
D the app supplies (only when a port is required, of course)? The second on=
e could be done with little additional code -- the app just needs to check =
if an additional port is needed when configuring the eventdev, and another =
helper function could take a list of <eventdev, ethdev> pairs and return tr=
ue if any don't have an inbuilt port.