From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <nikhil.rao@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id 95D812B91
for <dev@dpdk.org>; Wed, 16 Aug 2017 07:06:41 +0200 (CEST)
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
15 Aug 2017 22:06:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.41,381,1498546800"; d="scan'208";a="140794593"
Received: from nikhilr-mobl.amr.corp.intel.com (HELO [10.106.152.28])
([10.106.152.28])
by fmsmga006.fm.intel.com with ESMTP; 15 Aug 2017 22:06:36 -0700
To: Jerin Jacob <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>,
"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>
References: <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>
<9184057F7FC11744A2107296B6B8EB1E01F0EEF4@FMSMSX108.amr.corp.intel.com>
<20170810165319.GA6051@jerin>
<3fe6768a-7422-8006-5d37-961b0b31afa3@intel.com>
<20170814111001.GA12530@jerin>
From: "Rao, Nikhil" <nikhil.rao@intel.com>
Message-ID: <81597f6e-0038-41e8-9289-3cd7a34a0ecb@intel.com>
Date: Wed, 16 Aug 2017 10:36:35 +0530
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170814111001.GA12530@jerin>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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, 16 Aug 2017 05:06:43 -0000
On 8/14/2017 4:41 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Mon, 14 Aug 2017 14:18:15 +0530
>> From: "Rao, Nikhil" <nikhil.rao@intel.com>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, "Eads, Gage"
>> <gage.eads@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
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
>> Thunderbird/52.2.1
>>
>> On 8/10/2017 10:23 PM, Jerin Jacob wrote:
>>> -----Original Message-----
>>>> Date: Wed, 9 Aug 2017 19:24:30 +0000
>>>> From: "Eads, Gage" <gage.eads@intel.com>
>>>> 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 ID the app supplies (only when a port is required, of course)? The second one 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 true if any don't have an inbuilt port.
>>>
>>> I am in favor adding more logic in helper function(I believe, first one ) so that it will help
>>> application reuse the helper functions for the normal case.
>>>
>>
>> Hi Jerin,
>
> Hi Nikhil,
>
>>
>> My understanding of the discussion above is that the simple API adapter
>> creation API is
>>
>> int rte_event_eth_rx_adapter_create(id, eventdev_id)
>>
>> And the raw API is
>>
>> typedef int (*rx_adapter_conf_cb) (id, eventdev_id,
>> struct rte_event_eth_rx_adapter_conf *conf, void *arg);
>>
>> struct rte_event_eth_rx_adapter_conf {
>> uint8_t rx_event_port_id;
>> uint32_t max_nb_rx;
>> };
>>
>> int rte_event_eth_rx_adapter_create_ext(id, eventdev_id, conf_cb,
>> conf_arg)
>>
>> The conf_cb is invoked if the rte_event_eth_rx_adapter_conf struct needs to
>> be filled out. the _create_ext() API is used internally by
>> rte_event_eth_rx_adapter_create()
>>
>> Does that look OK to you ?
>
> Just elaborating with additional detail. Let me know my understating is correct
> or not?
Yes. Thanks for the clarification.
>
> default_cb(id, eventdev_id, conf)
> {
>
> conf->rx_event_port_id = rte_event_port() + 1;
> conf->max_nb_rx = ...;
> ....
> }
>
> rte_event_eth_rx_adapter_create(id, eventdev_id)
> {
> struct rte_event_eth_rx_adapter_conf default_conf_arg;
>
> rte_event_eth_rx_adapter_create_ext(id, eventdev_id,
> default_cb, &default_conf_arg);
> }
>
> Application is free to use rte_event_eth_rx_adapter_create() or
> rte_event_eth_rx_adapter_create_ext(). rte_event_eth_rx_adapter_create_ext()
> will be used by application when "default_cb" handler is not enough for
> the use cases.
>
>
>>
>> Nikhil
>>
>