[dpdk-dev,RFC] eventdev: add event adapter for ethernet Rx queues

  From: Nikhil Rao <nikhil.rao@intel.com>

Eventdev-based networking applications require a component to dequeue
packets from NIC Rx queues and inject them into eventdev queues[1]. While
some platforms (e.g. Cavium Octeontx) do this operation in hardware, other
platforms use software.

This RFC introduces an ethernet Rx event adapter and a proposed header
file. This adapter service dequeues packets from ethernet devices and
enqueues them to event devices.

The adapter is designed to work with the EAL service core proposal[2]. If
an application determines that the adapter is required, it can register and
launch it on a service core. Alternatively, this adapter can serve as a
template for applications to design customer ethernet Rx event adapters
better suited to their needs.

The adapter can service multiple ethernet devices and queues. Each queue 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 the 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/065207.html

Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
 lib/librte_eventdev/rte_eth_rx_event_adapter.h | 285 +++++++++++++++++++++++++
 lib/librte_eventdev/rte_eventdev_version.map   |  14 ++
 2 files changed, 299 insertions(+)
 create mode 100644 lib/librte_eventdev/rte_eth_rx_event_adapter.h
  

-----Original Message-----
> Date: Tue, 9 May 2017 15:38:46 -0500
> From: Gage Eads <gage.eads@intel.com>
> To: dev@dpdk.org
> CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com,
>  thomas@monjalon.net, bruce.richardson@intel.com,
>  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
>  narender.vangati@intel.com
> Subject: [RFC] eventdev: add event adapter for ethernet Rx queues
> X-Mailer: git-send-email 2.7.4
> 
> From: Nikhil Rao <nikhil.rao@intel.com>

Hi Nikhil and Gage,

Thanks for the RFC. A few questions and comments below.
Looks like SW has more constraints on event producer side, after we
finalize on this RFC(I guess only a few minor changes are only required).
I will align other[1] RFC based on _your_ RFC as we need to
converge on name space and we can't duplicate configs like struct
rte_event_dev_producer_conf etc

[1]
http://dpdk.org/ml/archives/dev/2017-May/065341.html

> 
> Eventdev-based networking applications require a component to dequeue
> packets from NIC Rx queues and inject them into eventdev queues[1]. While
> some platforms (e.g. Cavium Octeontx) do this operation in hardware, other
> platforms use software.
> 
> This RFC introduces an ethernet Rx event adapter and a proposed header
> file. This adapter service dequeues packets from ethernet devices and
> enqueues them to event devices.
> 
> The adapter is designed to work with the EAL service core proposal[2]. If
> an application determines that the adapter is required, it can register and
> launch it on a service core. Alternatively, this adapter can serve as a
> template for applications to design customer ethernet Rx event adapters
> better suited to their needs.
> 
> The adapter can service multiple ethernet devices and queues. Each queue 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 the 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/065207.html
> 
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> +
> +/**
> + * @file
> + *
> + * RTE Ethernet Rx Adapter for Eventdev
> + *
> + * 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 event device.
> + * The application uses the adapter APIs to configure the packet flow between
> + * the ethernet devices and event devices. The adapter is designed to 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 parallel.
> + *
> + * Before using the adapter, the application needs to enumerate and configure
> + * the ethernet devices that it wishes to use. This is typically done using the
> + * following DPDK ethdev functions:
> + *  - rte_eth_dev_configure()
> + *  - rte_eth_tx_queue_setup()
> + *  - rte_eth_rx_queue_setup()
> + *  - rte_eth_dev_start()
> + *
> + * The application also configures an event device and creates event ports
> + * to interface with the event device. In addition to the event ports used by
> + * its packet processing functions, the application creates an event port
> + * to be used by this adapter.
> + *
> + * The ethernet Rx event adapter's functions are:
> + *  - rte_eth_rx_event_adapter_create()
> + *  - rte_eth_rx_event_adapter_free()
> + *  - rte_eth_rx_event_adapter_dev_add()
> + *  - rte_eth_rx_event_adapter_dev_del()
> + *  - rte_eth_rx_event_adapter_queue_add()
> + *  - rte_eth_rx_event_adapter_run()
> + *  - rte_eth_rx_event_adapter_stats_get()
> + *  - rte_eth_rx_event_adapter_stats_reset()
> + *
> + * The applicaton creates an event to ethernet adapter using
> + * rte_eth_rx_event_adapter_create(). The event device and event port
> + * identifiers are passed to this function. Next, the application adds ethernet
> + * devices to this adapter using rte_eth_rx_event_adapter_dev_add().
> + *
> + * The adapter needs to know which ethernet rx queues to poll for mbufs as well
> + * as event device parameters such as the event queue identifier, event
> + * priority and scheduling type that the adapter should use when constructing
> + * events. The rte_eth_rx_event_adapter_queue_add() function is provided for
> + * this purpose.
> + *
> + * At the time of adding an ethernet device receive queue, the application can
> + * also specify a static event flow id and set the
> + * RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit of the rx_queue_flags
> + * member of the rte_eth_rx_event_adapter_queue_config structure. If the
> + * RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID isn't set, the flow id is
> + * assigned the value of the RSS hash. The adapter generates the RSS hash if it
> + * hasn't been already computed by the NIC, based on source and destination
> + * IPv4/6 addresses, using the rte_softrss_be() routine included in the DPDK.
> + *
> + * The servicing weight parameter in the rte_eth_rx_event_adapter_queue_config
> + * intended to provide application control of the polling frequency of ethernet
> + * device receive queues, for example, the application may want to poll higher
> + * priority queues with a higher frequency but at the same time not starve
> + * lower priority queues completely. If this parameter is zero and the receive
> + * interrupt is enabled when configuring the device, the receive queue is
> + * interrupt driven; else, the queue is assigned a servicing weight of one.

Looks good.

> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <stdint.h>
> +#include <rte_mbuf.h>
> +#include <rte_eventdev.h>
> +
> +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */
> +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID	0x1
> +/*< This flag indicates the flow identifier is valid */
> +
> +struct rte_eth_rx_event_adapter_config {

Since this code is going to be at lib/librte_eventdev, We must start all
public symbols and file name with rte_event_*.

example:
May be this structure can be changed as rte_event_eth_rx_adapter_config


> +	uint8_t event_dev_id;
> +	/**< Event device identifier */
> +	uint8_t rx_event_port_id;
> +	/**< Event port identifier, the adapter enqueues mbuf events to this
> +	 * port
> +	 */
> +};
> +
> +struct rte_eth_rx_event_adapter_queue_config {
> +	uint32_t rx_queue_flags;
> +	 /**< Flags for handling received packets */

Better to add references with @see
example:
	@see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID

> +	uint16_t servicing_weight;
> +	/**< Relative polling frequency of ethernet receive queue, if this
> +	 * is set to zero, the Rx queue is interrupt driven
> +	 */
> +	struct rte_event ev;
> +	/**<
> +	 *  The values from the following event fields will be used when
> +	 *  enqueuing mbuf events:
> +	 *   - event_queue_id: Targeted event queue ID for received packets.
> +	 *   - event_priority: Event priority of packets from this Rx queue in
> +	 *                     the event queue relative to other events.
> +	 *   - sched_type: Scheduling type for packets from this Rx queue.
> +	 *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
> +	 *		is set in rx_queue_flags, this flow_id is used for all
> +	 *		packets received from this queue. Otherwise the flow ID
> +	 *		is set to the RSS hash.

This scheme is good. I was duplicating the elements in "struct
rte_event_dev_producer_conf"

IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in
library.
You can mention that here as a info.

> +	 */
> +};
> +
> +struct rte_eth_rx_event_adapter_run_args {
> +	uint8_t id;
> +	/**< Adapter identifier */
> +	unsigned int max_nb_rx;
> +	/**< The adapter can return early if it has processed at least
> +	 * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> +	 * cause the adapter to process more than max_nb_rx mbufs.
> +	 */
> +};
> +
> +struct rte_eth_rx_event_adapter_stats {
> +	uint64_t rx_poll_count;
> +	/**< Receive queue poll count across both polled and interrupt mode
> +	 * queues
> +	 */
> +	uint64_t rx_packets;
> +	/**< Received packet count */
> +	uint64_t rx_enq_fail;
> +	/**< Eventdev enqueue failed count */
> +	uint64_t rx_enq_retry;
> +	/**< Eventdev enqueue retry count */
> +};
> +
> +/**
> + * Create a new ethernet Rx event adapter with the specified identifier.
> + *
> + * @param adapter_id
> + *   Event adapter identifier.
> + * @param config
> + *   Event adapter config parameters.
> + * @return
> + *   - 0: Success
> + *   - <0: Error code on failure
> + */
> +int rte_eth_rx_event_adapter_create(
> +	uint8_t id,
> +	const struct rte_eth_rx_event_adapter_config *config);
> +

One adapter creates one service function. right?
It is good to mention the mapping.It is missing in the doc.

> +/**
> + * Free an event adapter
> + *
> + * @param id
> + *   Adapter identifier.
> + * @return
> + *   - 0: Success
> + *   - <0: Error code on failure
> + */
> +int rte_eth_rx_event_adapter_free(uint8_t id);
> +
> +/**
> + * Add eth device to the event adapter
> + *
> + * @param id
> + *   Adapter identifier.
> + * @param eth_dev_id
> + *  Port identifier of the Ethernet device.
> + * @return
> + *   - 0: Success
> + *   - <0: Error code on failure
> + */
> +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id);

rte_eth_event_rx_queue_add() also have eth_dev_id.What is the
significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info.

if it is duplicate or it can be avoided then I propose to reduce the number
of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add,
rte_eth_rx_event_adapter_dev_del)

You can also mention the following for better clarify. If following is
true.If not, What do you think about, co-existence of poll and event mode?

The rte_eth_rx_burst() result is undefined if application invokes on
bounded ethdev_port and rx_queue_id.

> +
> +/**
> + * Delete eth device from an event adapter
> + *
> + * @param id
> + *   Adapter identifier.
> + * @param eth_dev_id
> + *  Port identifier of the Ethernet device.
> + * @return
> + *   - 0: Success
> + *   - <0: Error code on failure
> + */
> +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id);
> +
> +/**
> + * Add receive queue to event adapter
> + *
> + * @param id
> + *   Adapter identifier.
> + * @param eth_dev_id
> + *  Port identifier of Ethernet device.
> + * @param rx_queue_id
> + *  Ethernet device receive queue index.
> + * @param config
> + *  Additonal configuration structure.
> + * @return
> + *  - 0: Success, Receive queue added correctly.
> + *  - <0: Error code on failure.
> + */
> +int rte_eth_event_rx_queue_add(
> +	uint8_t id,
> +	uint8_t eth_dev_id,
> +	uint16_t rx_queue_id,

How about changing it as int32_t rx_queue_id and -1 to denote all Rx
queues configured for given eth_dev_id are added. This will avoid the
case where application needs to call this API one by one when application
interested in all the queues.

> +	const struct rte_eth_rx_event_adapter_queue_config *config);
> +

Don't we need rte_eth_event_rx_queue_del() for tear down?
  

11/05/2017 18:38, Jerin Jacob:
> > +struct rte_eth_rx_event_adapter_config {
> 
> Since this code is going to be at lib/librte_eventdev, We must start all
> public symbols and file name with rte_event_*.

+1, please do not mix the namespaces
  

Hi Jerin,

Comments inline.

Also, another function needed is
bool rte_event_eth_rx_adapter_multithread_capable(void). 

This would be used to set the "multithread_capable" service core 
configuration parameter. 

Thanks,
Nikhil

On 5/11/2017 10:08 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Tue, 9 May 2017 15:38:46 -0500
>> From: Gage Eads <gage.eads@intel.com>
>> To: dev@dpdk.org
>> CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com,
>>  thomas@monjalon.net, bruce.richardson@intel.com,
>>  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
>>  narender.vangati@intel.com
>> Subject: [RFC] eventdev: add event adapter for ethernet Rx queues
>> X-Mailer: git-send-email 2.7.4
>>
>> From: Nikhil Rao <nikhil.rao@intel.com>
> 
> Hi Nikhil and Gage,
> 
> Thanks for the RFC. A few questions and comments below.
> Looks like SW has more constraints on event producer side, after we
> finalize on this RFC(I guess only a few minor changes are only required).
> I will align other[1] RFC based on _your_ RFC as we need to
> converge on name space and we can't duplicate configs like struct
> rte_event_dev_producer_conf etc
> 
> [1]
> http://dpdk.org/ml/archives/dev/2017-May/065341.html
> 
>
> 
>> + */
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +#include <stdint.h>
>> +#include <rte_mbuf.h>
>> +#include <rte_eventdev.h>
>> +
>> +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */
>> +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID	0x1
>> +/*< This flag indicates the flow identifier is valid */
>> +
>> +struct rte_eth_rx_event_adapter_config {
> 
> Since this code is going to be at lib/librte_eventdev, We must start all
> public symbols and file name with rte_event_*.
> 
> example:
> May be this structure can be changed as rte_event_eth_rx_adapter_config

OK.

> 
> 
>> +	uint8_t event_dev_id;
>> +	/**< Event device identifier */
>> +	uint8_t rx_event_port_id;
>> +	/**< Event port identifier, the adapter enqueues mbuf events to this
>> +	 * port
>> +	 */
>> +};
>> +
>> +struct rte_eth_rx_event_adapter_queue_config {
>> +	uint32_t rx_queue_flags;
>> +	 /**< Flags for handling received packets */
> 
> Better to add references with @see
> example:
> 	@see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID

OK.

> 
>> +	uint16_t servicing_weight;
>> +	/**< Relative polling frequency of ethernet receive queue, if this
>> +	 * is set to zero, the Rx queue is interrupt driven
>> +	 */
>> +	struct rte_event ev;
>> +	/**<
>> +	 *  The values from the following event fields will be used when
>> +	 *  enqueuing mbuf events:
>> +	 *   - event_queue_id: Targeted event queue ID for received packets.
>> +	 *   - event_priority: Event priority of packets from this Rx queue in
>> +	 *                     the event queue relative to other events.
>> +	 *   - sched_type: Scheduling type for packets from this Rx queue.
>> +	 *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
>> +	 *		is set in rx_queue_flags, this flow_id is used for all
>> +	 *		packets received from this queue. Otherwise the flow ID
>> +	 *		is set to the RSS hash.
> 
> This scheme is good. I was duplicating the elements in "struct
> rte_event_dev_producer_conf"
> 
> IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in
> library.
> You can mention that here as a info.
OK.

> 
>> +	 */
>> +};
>> +
>> +struct rte_eth_rx_event_adapter_run_args {
>> +	uint8_t id;
>> +	/**< Adapter identifier */
>> +	unsigned int max_nb_rx;
>> +	/**< The adapter can return early if it has processed at least
>> +	 * max_nb_rx mbufs. This isn't treated as a requirement; batching may
>> +	 * cause the adapter to process more than max_nb_rx mbufs.
>> +	 */
>> +};
>> +
>> +struct rte_eth_rx_event_adapter_stats {
>> +	uint64_t rx_poll_count;
>> +	/**< Receive queue poll count across both polled and interrupt mode
>> +	 * queues
>> +	 */
>> +	uint64_t rx_packets;
>> +	/**< Received packet count */
>> +	uint64_t rx_enq_fail;
>> +	/**< Eventdev enqueue failed count */
>> +	uint64_t rx_enq_retry;
>> +	/**< Eventdev enqueue retry count */
>> +};
>> +
>> +/**
>> + * Create a new ethernet Rx event adapter with the specified identifier.
>> + *
>> + * @param adapter_id
>> + *   Event adapter identifier.
>> + * @param config
>> + *   Event adapter config parameters.
>> + * @return
>> + *   - 0: Success
>> + *   - <0: Error code on failure
>> + */
>> +int rte_eth_rx_event_adapter_create(
>> +	uint8_t id,
>> +	const struct rte_eth_rx_event_adapter_config *config);
>> +
> 
> One adapter creates one service function. right?
> It is good to mention the mapping.It is missing in the doc.

Yes, in this case, the application creates a service per adapter, it may create multiple
Rx event adapters with each adapter handling a subset of Rx queues. As per Harry's
patch, only DPDK internal components are expected to request service cores, once Harry posts
an updated patch, I will make any necesssary changes and post the next version of this
patch.

>> +/**
>> + * Free an event adapter
>> + *
>> + * @param id
>> + *   Adapter identifier.
>> + * @return
>> + *   - 0: Success
>> + *   - <0: Error code on failure
>> + */
>> +int rte_eth_rx_event_adapter_free(uint8_t id);
>> +
>> +/**
>> + * Add eth device to the event adapter
>> + *
>> + * @param id
>> + *   Adapter identifier.
>> + * @param eth_dev_id
>> + *  Port identifier of the Ethernet device.
>> + * @return
>> + *   - 0: Success
>> + *   - <0: Error code on failure
>> + */
>> +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id);
> 
> rte_eth_event_rx_queue_add() also have eth_dev_id.What is the
> significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info.
> 
> if it is duplicate or it can be avoided then I propose to reduce the number
> of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add,
> rte_eth_rx_event_adapter_dev_del)
OK.

> 
> You can also mention the following for better clarify. If following is
> true.If not, What do you think about, co-existence of poll and event mode?

Yes, its true.

> The rte_eth_rx_burst() result is undefined if application invokes on
> bounded ethdev_port and rx_queue_id.
> 
>> +
>> +/**
>> + * Delete eth device from an event adapter
>> + *
>> + * @param id
>> + *   Adapter identifier.
>> + * @param eth_dev_id
>> + *  Port identifier of the Ethernet device.
>> + * @return
>> + *   - 0: Success
>> + *   - <0: Error code on failure
>> + */
>> +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id);
>> +
>> +/**
>> + * Add receive queue to event adapter
>> + *
>> + * @param id
>> + *   Adapter identifier.
>> + * @param eth_dev_id
>> + *  Port identifier of Ethernet device.
>> + * @param rx_queue_id
>> + *  Ethernet device receive queue index.
>> + * @param config
>> + *  Additonal configuration structure.
>> + * @return
>> + *  - 0: Success, Receive queue added correctly.
>> + *  - <0: Error code on failure.
>> + */
>> +int rte_eth_event_rx_queue_add(
>> +	uint8_t id,
>> +	uint8_t eth_dev_id,
>> +	uint16_t rx_queue_id,
> 
> How about changing it as int32_t rx_queue_id and -1 to denote all Rx
> queues configured for given eth_dev_id are added. This will avoid the
> case where application needs to call this API one by one when application
> interested in all the queues.

Sounds good.
 
>> +	const struct rte_eth_rx_event_adapter_queue_config *config);
>> +
> 
> Don't we need rte_eth_event_rx_queue_del() for tear down?
> 
Yes.
  

-----Original Message-----
> Date: Wed, 24 May 2017 10:00:22 +0530
> From: "Rao, Nikhil" <nikhil.rao@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Gage Eads
>  <gage.eads@intel.com>
> CC: dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com,
>  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
>  narender.vangati@intel.com, nikhil.rao@intel.com
> Subject: Re: [RFC] eventdev: add event adapter for ethernet Rx queues
> User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
>  Thunderbird/38.7.2
> 
> Hi Jerin,

Hi Nikhil,

> 
> Comments inline.
> 
> Also, another function needed is
> bool rte_event_eth_rx_adapter_multithread_capable(void). 
> 
> This would be used to set the "multithread_capable" service core 
> configuration parameter. 

OK.

I was thinking like, in order to effectively use adapter scheme, it should
use ops scheme like rte_flow or rte_tm[1] where the same API can be
can be used for both HW and SW. If we see, Both RFC[2], We have a lot of
similarities. I think, We can base the eth_rx_adapter model based on your SW
requirement RFC and introduce capability wherever it is not applicable for HW or
vice versa.

See below as a example[3]. Can you take of the same in v1 of this
series? if you don't have the bandwidth then I can try. Let me know.
Thoughts?

[1]
http://dpdk.org/dev/patchwork/patch/25275/
http://dpdk.org/dev/patchwork/patch/25276/

[2]
http://dpdk.org/ml/archives/dev/2017-May/065341.html


/* adapter has inbuilt port, no need to create producer port */
#define RTE_EVENT_ETHDEV_CAP_INBUILT_PORT  (1ULL << 0)
/* adapter does not need service function */
#define RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC (1ULL << 1)

struct rte_event_eth_rx_adap_info {
	char name[32];
        uint32_t adapter_cap;
        /**< Ethdev RX adapter capabilities(RTE_EVENT_ETHDEV_CAP_)*/
}


struct rte_event_eth_rx_adap_cfg {
	uint8_t rx_event_port_id;
       /**< Event port identifier, the adapter enqueues mbuf events to this
        * port, Ignored when RTE_EVENT_ETHDEV_CAP_INBUILT_PORT
        */

}

struct rte_eth_rx_event_adapter_queue_config {
       uint32_t rx_queue_flags;
        /**< Flags for handling received packets */
       uint16_t servicing_weight;
       /**< Relative polling frequency of ethernet receive queue, if this
        * is set to zero, the Rx queue is interrupt driven
        * Ignored if RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC set
        */
       struct rte_event ev;
       /**<
        *  The values from the following event fields will be used when
        *  enqueuing mbuf events:
        *   - event_queue_id: Targeted event queue ID for received packets.
        *   - event_priority: Event priority of packets from this Rx queue in
        *                     the event queue relative to other events.
        *   - sched_type: Scheduling type for packets from this Rx queue.
        *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
        *               is set in rx_queue_flags, this flow_id is used for all
        *               packets received from this queue. Otherwise the flow ID
        *               is set to the RSS hash.
        */
};

int rte_event_eth_rx_adapter_create(uint8_t id, uint8_t dev_id, uint8_t eth_port_id);
int rte_event_eth_rx_adapter_get_info(uint8_t id, struct rte_event_eth_rx_adap_info *info);
int rte_event_eth_rx_adapter_configure(uint8_t id, struct rte_event_eth_rx_adap_config *cfg);
int rte_event_eth_rx_adapter_queue_add(uint8_t id, int32_t rx_queue_id, const struct rte_eth_rx_event_adapter_queue_config *config);
int rte_event_eth_rx_adapter_queue_del(uint8_t id, int32_t rx_queue_id)
int rte_event_eth_rx_adapter_run();
int rte_event_eth_rx_adapter_free(uint8_t id);



> 
> Thanks,
> Nikhil
> 
> On 5/11/2017 10:08 PM, Jerin Jacob wrote:
> > -----Original Message-----
> >> Date: Tue, 9 May 2017 15:38:46 -0500
> >> From: Gage Eads <gage.eads@intel.com>
> >> To: dev@dpdk.org
> >> CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com,
> >>  thomas@monjalon.net, bruce.richardson@intel.com,
> >>  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
> >>  narender.vangati@intel.com
> >> Subject: [RFC] eventdev: add event adapter for ethernet Rx queues
> >> X-Mailer: git-send-email 2.7.4
> >>
> >> From: Nikhil Rao <nikhil.rao@intel.com>
> > 
> > Hi Nikhil and Gage,
> > 
> > Thanks for the RFC. A few questions and comments below.
> > Looks like SW has more constraints on event producer side, after we
> > finalize on this RFC(I guess only a few minor changes are only required).
> > I will align other[1] RFC based on _your_ RFC as we need to
> > converge on name space and we can't duplicate configs like struct
> > rte_event_dev_producer_conf etc
> > 
> > [1]
> > http://dpdk.org/ml/archives/dev/2017-May/065341.html
> > 
> >
> > 
> >> + */
> >> +
> >> +#ifdef __cplusplus
> >> +extern "C" {
> >> +#endif
> >> +
> >> +#include <stdint.h>
> >> +#include <rte_mbuf.h>
> >> +#include <rte_eventdev.h>
> >> +
> >> +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */
> >> +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID	0x1
> >> +/*< This flag indicates the flow identifier is valid */
> >> +
> >> +struct rte_eth_rx_event_adapter_config {
> > 
> > Since this code is going to be at lib/librte_eventdev, We must start all
> > public symbols and file name with rte_event_*.
> > 
> > example:
> > May be this structure can be changed as rte_event_eth_rx_adapter_config
> 
> OK.
> 
> > 
> > 
> >> +	uint8_t event_dev_id;
> >> +	/**< Event device identifier */
> >> +	uint8_t rx_event_port_id;
> >> +	/**< Event port identifier, the adapter enqueues mbuf events to this
> >> +	 * port
> >> +	 */
> >> +};
> >> +
> >> +struct rte_eth_rx_event_adapter_queue_config {
> >> +	uint32_t rx_queue_flags;
> >> +	 /**< Flags for handling received packets */
> > 
> > Better to add references with @see
> > example:
> > 	@see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID
> 
> OK.
> 
> > 
> >> +	uint16_t servicing_weight;
> >> +	/**< Relative polling frequency of ethernet receive queue, if this
> >> +	 * is set to zero, the Rx queue is interrupt driven
> >> +	 */
> >> +	struct rte_event ev;
> >> +	/**<
> >> +	 *  The values from the following event fields will be used when
> >> +	 *  enqueuing mbuf events:
> >> +	 *   - event_queue_id: Targeted event queue ID for received packets.
> >> +	 *   - event_priority: Event priority of packets from this Rx queue in
> >> +	 *                     the event queue relative to other events.
> >> +	 *   - sched_type: Scheduling type for packets from this Rx queue.
> >> +	 *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
> >> +	 *		is set in rx_queue_flags, this flow_id is used for all
> >> +	 *		packets received from this queue. Otherwise the flow ID
> >> +	 *		is set to the RSS hash.
> > 
> > This scheme is good. I was duplicating the elements in "struct
> > rte_event_dev_producer_conf"
> > 
> > IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in
> > library.
> > You can mention that here as a info.
> OK.
> 
> > 
> >> +	 */
> >> +};
> >> +
> >> +struct rte_eth_rx_event_adapter_run_args {
> >> +	uint8_t id;
> >> +	/**< Adapter identifier */
> >> +	unsigned int max_nb_rx;
> >> +	/**< The adapter can return early if it has processed at least
> >> +	 * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> >> +	 * cause the adapter to process more than max_nb_rx mbufs.
> >> +	 */
> >> +};
> >> +
> >> +struct rte_eth_rx_event_adapter_stats {
> >> +	uint64_t rx_poll_count;
> >> +	/**< Receive queue poll count across both polled and interrupt mode
> >> +	 * queues
> >> +	 */
> >> +	uint64_t rx_packets;
> >> +	/**< Received packet count */
> >> +	uint64_t rx_enq_fail;
> >> +	/**< Eventdev enqueue failed count */
> >> +	uint64_t rx_enq_retry;
> >> +	/**< Eventdev enqueue retry count */
> >> +};
> >> +
> >> +/**
> >> + * Create a new ethernet Rx event adapter with the specified identifier.
> >> + *
> >> + * @param adapter_id
> >> + *   Event adapter identifier.
> >> + * @param config
> >> + *   Event adapter config parameters.
> >> + * @return
> >> + *   - 0: Success
> >> + *   - <0: Error code on failure
> >> + */
> >> +int rte_eth_rx_event_adapter_create(
> >> +	uint8_t id,
> >> +	const struct rte_eth_rx_event_adapter_config *config);
> >> +
> > 
> > One adapter creates one service function. right?
> > It is good to mention the mapping.It is missing in the doc.
> 
> Yes, in this case, the application creates a service per adapter, it may create multiple
> Rx event adapters with each adapter handling a subset of Rx queues. As per Harry's
> patch, only DPDK internal components are expected to request service cores, once Harry posts
> an updated patch, I will make any necesssary changes and post the next version of this
> patch.
> 
> >> +/**
> >> + * Free an event adapter
> >> + *
> >> + * @param id
> >> + *   Adapter identifier.
> >> + * @return
> >> + *   - 0: Success
> >> + *   - <0: Error code on failure
> >> + */
> >> +int rte_eth_rx_event_adapter_free(uint8_t id);
> >> +
> >> +/**
> >> + * Add eth device to the event adapter
> >> + *
> >> + * @param id
> >> + *   Adapter identifier.
> >> + * @param eth_dev_id
> >> + *  Port identifier of the Ethernet device.
> >> + * @return
> >> + *   - 0: Success
> >> + *   - <0: Error code on failure
> >> + */
> >> +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id);
> > 
> > rte_eth_event_rx_queue_add() also have eth_dev_id.What is the
> > significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info.
> > 
> > if it is duplicate or it can be avoided then I propose to reduce the number
> > of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add,
> > rte_eth_rx_event_adapter_dev_del)
> OK.
> 
> > 
> > You can also mention the following for better clarify. If following is
> > true.If not, What do you think about, co-existence of poll and event mode?
> 
> Yes, its true.
> 
> > The rte_eth_rx_burst() result is undefined if application invokes on
> > bounded ethdev_port and rx_queue_id.
> > 
> >> +
> >> +/**
> >> + * Delete eth device from an event adapter
> >> + *
> >> + * @param id
> >> + *   Adapter identifier.
> >> + * @param eth_dev_id
> >> + *  Port identifier of the Ethernet device.
> >> + * @return
> >> + *   - 0: Success
> >> + *   - <0: Error code on failure
> >> + */
> >> +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id);
> >> +
> >> +/**
> >> + * Add receive queue to event adapter
> >> + *
> >> + * @param id
> >> + *   Adapter identifier.
> >> + * @param eth_dev_id
> >> + *  Port identifier of Ethernet device.
> >> + * @param rx_queue_id
> >> + *  Ethernet device receive queue index.
> >> + * @param config
> >> + *  Additonal configuration structure.
> >> + * @return
> >> + *  - 0: Success, Receive queue added correctly.
> >> + *  - <0: Error code on failure.
> >> + */
> >> +int rte_eth_event_rx_queue_add(
> >> +	uint8_t id,
> >> +	uint8_t eth_dev_id,
> >> +	uint16_t rx_queue_id,
> > 
> > How about changing it as int32_t rx_queue_id and -1 to denote all Rx
> > queues configured for given eth_dev_id are added. This will avoid the
> > case where application needs to call this API one by one when application
> > interested in all the queues.
> 
> Sounds good.
>  
> >> +	const struct rte_eth_rx_event_adapter_queue_config *config);
> >> +
> > 
> > Don't we need rte_eth_event_rx_queue_del() for tear down?
> > 
> Yes.
  

-----Original Message-----
> Date: Mon, 19 Jun 2017 15:35:22 +0530
> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> To: "Rao, Nikhil" <nikhil.rao@intel.com>
> CC: Gage Eads <gage.eads@intel.com>, dev@dpdk.org, thomas@monjalon.net,
>  bruce.richardson@intel.com, harry.van.haaren@intel.com,
>  hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com
> Subject: Re: [dpdk-dev] [RFC] eventdev: add event adapter for ethernet Rx
>  queues
> User-Agent: Mutt/1.8.3 (2017-05-23)
> 
> -----Original Message-----
> > Date: Wed, 24 May 2017 10:00:22 +0530
> > From: "Rao, Nikhil" <nikhil.rao@intel.com>
> > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Gage Eads
> >  <gage.eads@intel.com>
> > CC: dev@dpdk.org, thomas@monjalon.net, bruce.richardson@intel.com,
> >  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
> >  narender.vangati@intel.com, nikhil.rao@intel.com
> > Subject: Re: [RFC] eventdev: add event adapter for ethernet Rx queues
> > User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
> >  Thunderbird/38.7.2
> > 
> > Hi Jerin,
> 
> Hi Nikhil,
> 
> > 
> > Comments inline.
> > 
> > Also, another function needed is
> > bool rte_event_eth_rx_adapter_multithread_capable(void). 
> > 
> > This would be used to set the "multithread_capable" service core 
> > configuration parameter. 
> 
> OK.
> 
> I was thinking like, in order to effectively use adapter scheme, it should
> use ops scheme like rte_flow or rte_tm[1] where the same API can be
> can be used for both HW and SW. If we see, Both RFC[2], We have a lot of
> similarities. I think, We can base the eth_rx_adapter model based on your SW
> requirement RFC and introduce capability wherever it is not applicable for HW or
> vice versa.
> 
> See below as a example[3]. Can you take of the same in v1 of this
> series? if you don't have the bandwidth then I can try. Let me know.

Nikhil,

Now that Harry send first version of service core patch? Are you
planning for new version with above comments?

> Thoughts?
> 
> [1]
> http://dpdk.org/dev/patchwork/patch/25275/
> http://dpdk.org/dev/patchwork/patch/25276/
> 
> [2]
> http://dpdk.org/ml/archives/dev/2017-May/065341.html
> 
> 
> /* adapter has inbuilt port, no need to create producer port */
> #define RTE_EVENT_ETHDEV_CAP_INBUILT_PORT  (1ULL << 0)
> /* adapter does not need service function */
> #define RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC (1ULL << 1)
> 
> struct rte_event_eth_rx_adap_info {
> 	char name[32];
>         uint32_t adapter_cap;
>         /**< Ethdev RX adapter capabilities(RTE_EVENT_ETHDEV_CAP_)*/
> }
> 
> 
> struct rte_event_eth_rx_adap_cfg {
> 	uint8_t rx_event_port_id;
>        /**< Event port identifier, the adapter enqueues mbuf events to this
>         * port, Ignored when RTE_EVENT_ETHDEV_CAP_INBUILT_PORT
>         */
> 
> }
> 
> struct rte_eth_rx_event_adapter_queue_config {
>        uint32_t rx_queue_flags;
>         /**< Flags for handling received packets */
>        uint16_t servicing_weight;
>        /**< Relative polling frequency of ethernet receive queue, if this
>         * is set to zero, the Rx queue is interrupt driven
>         * Ignored if RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC set
>         */
>        struct rte_event ev;
>        /**<
>         *  The values from the following event fields will be used when
>         *  enqueuing mbuf events:
>         *   - event_queue_id: Targeted event queue ID for received packets.
>         *   - event_priority: Event priority of packets from this Rx queue in
>         *                     the event queue relative to other events.
>         *   - sched_type: Scheduling type for packets from this Rx queue.
>         *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
>         *               is set in rx_queue_flags, this flow_id is used for all
>         *               packets received from this queue. Otherwise the flow ID
>         *               is set to the RSS hash.
>         */
> };
> 
> int rte_event_eth_rx_adapter_create(uint8_t id, uint8_t dev_id, uint8_t eth_port_id);
> int rte_event_eth_rx_adapter_get_info(uint8_t id, struct rte_event_eth_rx_adap_info *info);
> int rte_event_eth_rx_adapter_configure(uint8_t id, struct rte_event_eth_rx_adap_config *cfg);
> int rte_event_eth_rx_adapter_queue_add(uint8_t id, int32_t rx_queue_id, const struct rte_eth_rx_event_adapter_queue_config *config);
> int rte_event_eth_rx_adapter_queue_del(uint8_t id, int32_t rx_queue_id)
> int rte_event_eth_rx_adapter_run();
> int rte_event_eth_rx_adapter_free(uint8_t id);
> 
> 
> 
> > 
> > Thanks,
> > Nikhil
> > 
> > On 5/11/2017 10:08 PM, Jerin Jacob wrote:
> > > -----Original Message-----
> > >> Date: Tue, 9 May 2017 15:38:46 -0500
> > >> From: Gage Eads <gage.eads@intel.com>
> > >> To: dev@dpdk.org
> > >> CC: nikhil.rao@intel.com, jerin.jacob@caviumnetworks.com,
> > >>  thomas@monjalon.net, bruce.richardson@intel.com,
> > >>  harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com,
> > >>  narender.vangati@intel.com
> > >> Subject: [RFC] eventdev: add event adapter for ethernet Rx queues
> > >> X-Mailer: git-send-email 2.7.4
> > >>
> > >> From: Nikhil Rao <nikhil.rao@intel.com>
> > > 
> > > Hi Nikhil and Gage,
> > > 
> > > Thanks for the RFC. A few questions and comments below.
> > > Looks like SW has more constraints on event producer side, after we
> > > finalize on this RFC(I guess only a few minor changes are only required).
> > > I will align other[1] RFC based on _your_ RFC as we need to
> > > converge on name space and we can't duplicate configs like struct
> > > rte_event_dev_producer_conf etc
> > > 
> > > [1]
> > > http://dpdk.org/ml/archives/dev/2017-May/065341.html
> > > 
> > >
> > > 
> > >> + */
> > >> +
> > >> +#ifdef __cplusplus
> > >> +extern "C" {
> > >> +#endif
> > >> +
> > >> +#include <stdint.h>
> > >> +#include <rte_mbuf.h>
> > >> +#include <rte_eventdev.h>
> > >> +
> > >> +/* struct rte_eth_rx_event_adapter_queue_config flags definitions */
> > >> +#define RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID	0x1
> > >> +/*< This flag indicates the flow identifier is valid */
> > >> +
> > >> +struct rte_eth_rx_event_adapter_config {
> > > 
> > > Since this code is going to be at lib/librte_eventdev, We must start all
> > > public symbols and file name with rte_event_*.
> > > 
> > > example:
> > > May be this structure can be changed as rte_event_eth_rx_adapter_config
> > 
> > OK.
> > 
> > > 
> > > 
> > >> +	uint8_t event_dev_id;
> > >> +	/**< Event device identifier */
> > >> +	uint8_t rx_event_port_id;
> > >> +	/**< Event port identifier, the adapter enqueues mbuf events to this
> > >> +	 * port
> > >> +	 */
> > >> +};
> > >> +
> > >> +struct rte_eth_rx_event_adapter_queue_config {
> > >> +	uint32_t rx_queue_flags;
> > >> +	 /**< Flags for handling received packets */
> > > 
> > > Better to add references with @see
> > > example:
> > > 	@see RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID
> > 
> > OK.
> > 
> > > 
> > >> +	uint16_t servicing_weight;
> > >> +	/**< Relative polling frequency of ethernet receive queue, if this
> > >> +	 * is set to zero, the Rx queue is interrupt driven
> > >> +	 */
> > >> +	struct rte_event ev;
> > >> +	/**<
> > >> +	 *  The values from the following event fields will be used when
> > >> +	 *  enqueuing mbuf events:
> > >> +	 *   - event_queue_id: Targeted event queue ID for received packets.
> > >> +	 *   - event_priority: Event priority of packets from this Rx queue in
> > >> +	 *                     the event queue relative to other events.
> > >> +	 *   - sched_type: Scheduling type for packets from this Rx queue.
> > >> +	 *   - flow_id: If the RTE_ETH_RX_EVENT_ADAPTER_QUEUE_FLOW_ID_VALID bit
> > >> +	 *		is set in rx_queue_flags, this flow_id is used for all
> > >> +	 *		packets received from this queue. Otherwise the flow ID
> > >> +	 *		is set to the RSS hash.
> > > 
> > > This scheme is good. I was duplicating the elements in "struct
> > > rte_event_dev_producer_conf"
> > > 
> > > IMO, We need to set ev.event_type == RTE_EVENT_TYPE_ETHDEV implicitly in
> > > library.
> > > You can mention that here as a info.
> > OK.
> > 
> > > 
> > >> +	 */
> > >> +};
> > >> +
> > >> +struct rte_eth_rx_event_adapter_run_args {
> > >> +	uint8_t id;
> > >> +	/**< Adapter identifier */
> > >> +	unsigned int max_nb_rx;
> > >> +	/**< The adapter can return early if it has processed at least
> > >> +	 * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> > >> +	 * cause the adapter to process more than max_nb_rx mbufs.
> > >> +	 */
> > >> +};
> > >> +
> > >> +struct rte_eth_rx_event_adapter_stats {
> > >> +	uint64_t rx_poll_count;
> > >> +	/**< Receive queue poll count across both polled and interrupt mode
> > >> +	 * queues
> > >> +	 */
> > >> +	uint64_t rx_packets;
> > >> +	/**< Received packet count */
> > >> +	uint64_t rx_enq_fail;
> > >> +	/**< Eventdev enqueue failed count */
> > >> +	uint64_t rx_enq_retry;
> > >> +	/**< Eventdev enqueue retry count */
> > >> +};
> > >> +
> > >> +/**
> > >> + * Create a new ethernet Rx event adapter with the specified identifier.
> > >> + *
> > >> + * @param adapter_id
> > >> + *   Event adapter identifier.
> > >> + * @param config
> > >> + *   Event adapter config parameters.
> > >> + * @return
> > >> + *   - 0: Success
> > >> + *   - <0: Error code on failure
> > >> + */
> > >> +int rte_eth_rx_event_adapter_create(
> > >> +	uint8_t id,
> > >> +	const struct rte_eth_rx_event_adapter_config *config);
> > >> +
> > > 
> > > One adapter creates one service function. right?
> > > It is good to mention the mapping.It is missing in the doc.
> > 
> > Yes, in this case, the application creates a service per adapter, it may create multiple
> > Rx event adapters with each adapter handling a subset of Rx queues. As per Harry's
> > patch, only DPDK internal components are expected to request service cores, once Harry posts
> > an updated patch, I will make any necesssary changes and post the next version of this
> > patch.
> > 
> > >> +/**
> > >> + * Free an event adapter
> > >> + *
> > >> + * @param id
> > >> + *   Adapter identifier.
> > >> + * @return
> > >> + *   - 0: Success
> > >> + *   - <0: Error code on failure
> > >> + */
> > >> +int rte_eth_rx_event_adapter_free(uint8_t id);
> > >> +
> > >> +/**
> > >> + * Add eth device to the event adapter
> > >> + *
> > >> + * @param id
> > >> + *   Adapter identifier.
> > >> + * @param eth_dev_id
> > >> + *  Port identifier of the Ethernet device.
> > >> + * @return
> > >> + *   - 0: Success
> > >> + *   - <0: Error code on failure
> > >> + */
> > >> +int rte_eth_rx_event_adapter_dev_add(uint8_t id, uint8_t eth_dev_id);
> > > 
> > > rte_eth_event_rx_queue_add() also have eth_dev_id.What is the
> > > significance of eth_dev_id here. Looks like eth_dev_id is a duplicate info.
> > > 
> > > if it is duplicate or it can be avoided then I propose to reduce the number
> > > of APIs for easiness of application programming(i.e removing rte_eth_rx_event_adapter_dev_add,
> > > rte_eth_rx_event_adapter_dev_del)
> > OK.
> > 
> > > 
> > > You can also mention the following for better clarify. If following is
> > > true.If not, What do you think about, co-existence of poll and event mode?
> > 
> > Yes, its true.
> > 
> > > The rte_eth_rx_burst() result is undefined if application invokes on
> > > bounded ethdev_port and rx_queue_id.
> > > 
> > >> +
> > >> +/**
> > >> + * Delete eth device from an event adapter
> > >> + *
> > >> + * @param id
> > >> + *   Adapter identifier.
> > >> + * @param eth_dev_id
> > >> + *  Port identifier of the Ethernet device.
> > >> + * @return
> > >> + *   - 0: Success
> > >> + *   - <0: Error code on failure
> > >> + */
> > >> +int rte_eth_rx_event_adapter_dev_del(uint8_t id, uint8_t eth_dev_id);
> > >> +
> > >> +/**
> > >> + * Add receive queue to event adapter
> > >> + *
> > >> + * @param id
> > >> + *   Adapter identifier.
> > >> + * @param eth_dev_id
> > >> + *  Port identifier of Ethernet device.
> > >> + * @param rx_queue_id
> > >> + *  Ethernet device receive queue index.
> > >> + * @param config
> > >> + *  Additonal configuration structure.
> > >> + * @return
> > >> + *  - 0: Success, Receive queue added correctly.
> > >> + *  - <0: Error code on failure.
> > >> + */
> > >> +int rte_eth_event_rx_queue_add(
> > >> +	uint8_t id,
> > >> +	uint8_t eth_dev_id,
> > >> +	uint16_t rx_queue_id,
> > > 
> > > How about changing it as int32_t rx_queue_id and -1 to denote all Rx
> > > queues configured for given eth_dev_id are added. This will avoid the
> > > case where application needs to call this API one by one when application
> > > interested in all the queues.
> > 
> > Sounds good.
> >  
> > >> +	const struct rte_eth_rx_event_adapter_queue_config *config);
> > >> +
> > > 
> > > Don't we need rte_eth_event_rx_queue_del() for tear down?
> > > 
> > Yes.
  

On 6/26/2017 6:49 PM, Jerin Jacob wrote:
>
> 
> Nikhil,
> 
> Now that Harry send first version of service core patch? Are you
> planning for new version with above comments?
> 

Yes. I will post a new version.

Thanks,
Nikhil