Re: [dpdk-dev] [PATCH] cryptodev: build on Windows
On Mon, Sep 13, 2021 at 10:19 AM Tal Shnaiderman wrote: > > Build the cryptography device library on Windows OS > by removing unneeded include and exports blocking the > compilation. > > Signed-off-by: Tal Shnaiderman Acked-by: William Tu I sent similar patch to enable ixgbe support for windows. http://inbox.dpdk.org/dev/CALDO+SY_YkdV+Dx-dUJx8cyqafL6HdL=09drogcubeonh2b...@mail.gmail.com/T/#t
Re: [dpdk-dev] [PATCH 1/2] security: use the net library for IP structs
On Wed, Sep 15, 2021 at 9:27 AM Tal Shnaiderman wrote: > > Remove the netinet includes and replaces them > with rte_ip.h to support the in_addr/in6_addr structs > on all operating systems. > > Signed-off-by: Tal Shnaiderman > --- Acked-by: William Tu I sent a similar patch to enable ixgbe support for windows. http://inbox.dpdk.org/dev/CALDO+SY_YkdV+Dx-dUJx8cyqafL6HdL=09drogcubeonh2b...@mail.gmail.com/T/#t
Re: [dpdk-dev] [PATCH 2/2] security: build on Windows
On Wed, Sep 15, 2021 at 9:27 AM Tal Shnaiderman wrote: > > Build the security library on Windows. > > Remove unneeded export from version file. > > Signed-off-by: Tal Shnaiderman > --- Acked-by: William Tu
Re: [dpdk-dev] [PATCH v3] eventdev: update crypto adapter metadata structures
Hi Shijith & Anoob,
> -Original Message-
> From: Anoob Joseph
> Sent: Tuesday, September 14, 2021 10:16 AM
> To: Gujjar, Abhinandan S
> Cc: Jerin Jacob Kollanukkaran ; Pavan Nikhilesh
> Bhagavatula ; Akhil Goyal
> ; Ray Kinsella ; Ankur Dwivedi
> ; Shijith Thotton ;
> dev@dpdk.org
> Subject: RE: [PATCH v3] eventdev: update crypto adapter metadata
> structures
>
> Hi Abhinandan, Shijith,
>
> Please see inline.
>
> Thanks,
> Anoob
>
> > -Original Message-
> > From: Shijith Thotton
> > Sent: Tuesday, September 14, 2021 10:07 AM
> > To: Gujjar, Abhinandan S ; dev@dpdk.org
> > Cc: Jerin Jacob Kollanukkaran ; Anoob Joseph
> > ; Pavan Nikhilesh Bhagavatula
> > ; Akhil Goyal ; Ray
> > Kinsella ; Ankur Dwivedi
> > Subject: RE: [PATCH v3] eventdev: update crypto adapter metadata
> > structures
> >
> > >> >>
> > >> >> >> In crypto adapter metadata, reserved bytes in request info
> > >> >> >> structure is a space holder for response info. It enforces an
> > >> >> >> order of operation if the structures are updated using memcpy
> > >> >> >> to avoid overwriting response info. It is logical to move the
> > >> >> >> reserved space out of request info. It also solves the
> > >> >> >> ordering issue
> > >> mentioned before.
> > >> >> >I would like to understand what kind of ordering issue you have
> > >> >> >faced with the current approach. Could you please give an
> > >> >> >example/sequence
> > >> >> and explain?
> > >> >> >
> > >> >>
> > >> >> I have seen this issue with crypto adapter autotest (#n215).
> > >> >>
> > >> >> Example:
> > >> >> rte_memcpy(&m_data.response_info, &response_info,
> > >> >> sizeof(response_info)); rte_memcpy(&m_data.request_info,
> > >> >> &request_info, sizeof(request_info));
> > >> >>
> > >> >> Here response info is getting overwritten by request info.
> > >> >> Above lines can reordered to fix the issue, but can be ignored
> > >> >> with this
> > >> patch.
> > >> >There is a reason for designing the metadata in this way.
> > >> >Right now, sizeof (union rte_event_crypto_metadata) is 16 bytes.
> > >> >So, the session based case needs just 16 bytes to store the data.
> > >> >Whereas, for sessionless case each crypto_ops requires another 16
> > bytes.
> > >> >
> > >> >By changing the struct in the following way you are doubling the
> > >> >memory requirement.
> > >> >With the changes, for sessionless case, each crypto op requires 32
> > >> >bytes of space instead of 16 bytes and the mempool will be bigger.
> > >> >This will have the perf impact too!
> > >> >
> > >> >You can just copy the individual members(cdev_id & queue_pair_id)
> > >> >after the response_info.
> > >> >OR You have a better way?
> > >> >
> > >>
> > >> I missed the second word of event structure. It adds an extra 8
> > >> bytes, which is not required.
> > >I guess you meant not adding, it is overlapping with request information.
> > >> Let me know, what you think of below change to metadata structure.
> > >>
> > >> struct rte_event_crypto_metadata {
> > >> uint64_t response_info; // 8 bytes
> > >With this, it lags clarity saying it is an event information.
> > >> struct rte_event_crypto_request request_info; // 8 bytes };
> > >>
> > >> Total structure size is 16 bytes.
> > >>
> > >> Response info can be set like below in test app:
> > >> m_data.response_info = response_info.event;
> > >>
> > >> The main aim of this patch is to decouple response info from request
> info.
> > >The decoupling was required as it was doing memcpy.
> > >If you copy the individual members of request info(after response),
> > >you don't require it.
> >
> > With this change, the application will be free of such constraints.
>
> [Anoob] Why don't we make it like,
>
> struct rte_event_crypto_metadata {
> uint64_t ev_w0_template;
> /**< Template of the first word of ``struct rte_event``
> (rte_event.event) to be set in the events generated by crypto adapter in
> both RTE_EVENT_CRYPTO_ADAPTER_OP_NEW and
>* RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD modes.
> */
> struct rte_event_crypto_request request_info; };
>
> This way, the usage would become more obvious and we will not have
> additional space reserved as well.
Thanks for the suggestion. At this point, it is like an application without
understanding the data structure/ internals
has used memcpy and we are trying to fix it by changing the actual data
structure instead of fixing the application!
With this patch, the other applications(outside of dpdk) which are using the
data structures in a right are forced to change!
I don't think, this is the right way to handle this. I think, we should be
updating the test case and documentation for this rather
than changing the data structure. I expect the next version of this patch
should have those changes. Thanks!
>
> >
> > >>
> > >> >>
> > >> >> >>
> > >> >> >> This patch removes the reserve field from request info and
> > >> >> >> makes event crypto metadata type to structure from union t
Re: [dpdk-dev] [PATCH v3] eventdev: update crypto adapter metadata structures
Hi Abhinandan,
> > > >> >>
> > > >> >> >> In crypto adapter metadata, reserved bytes in request info
> > > >> >> >> structure is a space holder for response info. It enforces an
> > > >> >> >> order of operation if the structures are updated using memcpy
> > > >> >> >> to avoid overwriting response info. It is logical to move the
> > > >> >> >> reserved space out of request info. It also solves the
> > > >> >> >> ordering issue
> > > >> mentioned before.
> > > >> >> >I would like to understand what kind of ordering issue you have
> > > >> >> >faced with the current approach. Could you please give an
> > > >> >> >example/sequence
> > > >> >> and explain?
> > > >> >> >
> > > >> >>
> > > >> >> I have seen this issue with crypto adapter autotest (#n215).
> > > >> >>
> > > >> >> Example:
> > > >> >> rte_memcpy(&m_data.response_info, &response_info,
> > > >> >> sizeof(response_info)); rte_memcpy(&m_data.request_info,
> > > >> >> &request_info, sizeof(request_info));
> > > >> >>
> > > >> >> Here response info is getting overwritten by request info.
> > > >> >> Above lines can reordered to fix the issue, but can be ignored
> > > >> >> with this
> > > >> patch.
> > > >> >There is a reason for designing the metadata in this way.
> > > >> >Right now, sizeof (union rte_event_crypto_metadata) is 16 bytes.
> > > >> >So, the session based case needs just 16 bytes to store the data.
> > > >> >Whereas, for sessionless case each crypto_ops requires another 16
> > > bytes.
> > > >> >
> > > >> >By changing the struct in the following way you are doubling the
> > > >> >memory requirement.
> > > >> >With the changes, for sessionless case, each crypto op requires 32
> > > >> >bytes of space instead of 16 bytes and the mempool will be bigger.
> > > >> >This will have the perf impact too!
> > > >> >
> > > >> >You can just copy the individual members(cdev_id & queue_pair_id)
> > > >> >after the response_info.
> > > >> >OR You have a better way?
> > > >> >
> > > >>
> > > >> I missed the second word of event structure. It adds an extra 8
> > > >> bytes, which is not required.
> > > >I guess you meant not adding, it is overlapping with request
> information.
> > > >> Let me know, what you think of below change to metadata structure.
> > > >>
> > > >> struct rte_event_crypto_metadata {
> > > >>uint64_t response_info; // 8 bytes
> > > >With this, it lags clarity saying it is an event information.
> > > >>struct rte_event_crypto_request request_info; // 8 bytes };
> > > >>
> > > >> Total structure size is 16 bytes.
> > > >>
> > > >> Response info can be set like below in test app:
> > > >>m_data.response_info = response_info.event;
> > > >>
> > > >> The main aim of this patch is to decouple response info from request
> > info.
> > > >The decoupling was required as it was doing memcpy.
> > > >If you copy the individual members of request info(after response),
> > > >you don't require it.
> > >
> > > With this change, the application will be free of such constraints.
> >
> > [Anoob] Why don't we make it like,
> >
> > struct rte_event_crypto_metadata {
> > uint64_t ev_w0_template;
> > /**< Template of the first word of ``struct rte_event``
> > (rte_event.event) to be set in the events generated by crypto adapter in
> > both RTE_EVENT_CRYPTO_ADAPTER_OP_NEW and
> > * RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD modes.
> > */
> > struct rte_event_crypto_request request_info; };
> >
> > This way, the usage would become more obvious and we will not have
> > additional space reserved as well.
>
> Thanks for the suggestion. At this point, it is like an application without
> understanding the data structure/ internals
> has used memcpy and we are trying to fix it by changing the actual data
> structure instead of fixing the application!
> With this patch, the other applications(outside of dpdk) which are using the
> data structures in a right are forced to change!
> I don't think, this is the right way to handle this. I think, we should be
> updating the test case and documentation for this rather
> than changing the data structure. I expect the next version of this patch
> should have those changes. Thanks!
The point here is about making the specification better and clearer to the user.
If the structure is not clear and is error prone if somebody does not follow
Proper documentation, we can modify it to reduce possible issues.
This is a cleanup which was added in deprecation notice as well in the last
release.
This is a ABI break release and we should do this cleanup if it is legit.
Applications outside DPDK are notified as per the deprecation notice in the
last release.
We have followed standard procedure to modify this structure,
hence, no need to worry about that.
We have provided, 2-3 suggestions to clean this up. Please suggest which
one is best for Intel use case.
Having first element as reserved in the structure doesn't look quite obvious.
This was also highlighted in the original patch,
Re: [dpdk-dev] [PATCH v3] eventdev: update crypto adapter metadata structures
Hi Akhil,
> -Original Message-
> From: Akhil Goyal
> Sent: Monday, September 20, 2021 12:19 AM
> To: Gujjar, Abhinandan S ; Anoob Joseph
> ; Shijith Thotton
> Cc: Jerin Jacob Kollanukkaran ; Pavan Nikhilesh
> Bhagavatula ; Ray Kinsella ;
> Ankur Dwivedi ; dev@dpdk.org;
> tho...@monjalon.net; nipun.gu...@nxp.com; Hemant Agrawal
>
> Subject: RE: [PATCH v3] eventdev: update crypto adapter metadata
> structures
>
> Hi Abhinandan,
> > > > >> >>
> > > > >> >> >> In crypto adapter metadata, reserved bytes in request
> > > > >> >> >> info structure is a space holder for response info. It
> > > > >> >> >> enforces an order of operation if the structures are
> > > > >> >> >> updated using memcpy to avoid overwriting response info.
> > > > >> >> >> It is logical to move the reserved space out of request
> > > > >> >> >> info. It also solves the ordering issue
> > > > >> mentioned before.
> > > > >> >> >I would like to understand what kind of ordering issue you
> > > > >> >> >have faced with the current approach. Could you please give
> > > > >> >> >an example/sequence
> > > > >> >> and explain?
> > > > >> >> >
> > > > >> >>
> > > > >> >> I have seen this issue with crypto adapter autotest (#n215).
> > > > >> >>
> > > > >> >> Example:
> > > > >> >> rte_memcpy(&m_data.response_info, &response_info,
> > > > >> >> sizeof(response_info)); rte_memcpy(&m_data.request_info,
> > > > >> >> &request_info, sizeof(request_info));
> > > > >> >>
> > > > >> >> Here response info is getting overwritten by request info.
> > > > >> >> Above lines can reordered to fix the issue, but can be
> > > > >> >> ignored with this
> > > > >> patch.
> > > > >> >There is a reason for designing the metadata in this way.
> > > > >> >Right now, sizeof (union rte_event_crypto_metadata) is 16 bytes.
> > > > >> >So, the session based case needs just 16 bytes to store the data.
> > > > >> >Whereas, for sessionless case each crypto_ops requires another
> > > > >> >16
> > > > bytes.
> > > > >> >
> > > > >> >By changing the struct in the following way you are doubling
> > > > >> >the memory requirement.
> > > > >> >With the changes, for sessionless case, each crypto op
> > > > >> >requires 32 bytes of space instead of 16 bytes and the mempool
> will be bigger.
> > > > >> >This will have the perf impact too!
> > > > >> >
> > > > >> >You can just copy the individual members(cdev_id &
> > > > >> >queue_pair_id) after the response_info.
> > > > >> >OR You have a better way?
> > > > >> >
> > > > >>
> > > > >> I missed the second word of event structure. It adds an extra 8
> > > > >> bytes, which is not required.
> > > > >I guess you meant not adding, it is overlapping with request
> > information.
> > > > >> Let me know, what you think of below change to metadata
> structure.
> > > > >>
> > > > >> struct rte_event_crypto_metadata {
> > > > >> uint64_t response_info; // 8 bytes
> > > > >With this, it lags clarity saying it is an event information.
> > > > >> struct rte_event_crypto_request request_info; // 8 bytes };
> > > > >>
> > > > >> Total structure size is 16 bytes.
> > > > >>
> > > > >> Response info can be set like below in test app:
> > > > >> m_data.response_info = response_info.event;
> > > > >>
> > > > >> The main aim of this patch is to decouple response info from
> > > > >> request
> > > info.
> > > > >The decoupling was required as it was doing memcpy.
> > > > >If you copy the individual members of request info(after
> > > > >response), you don't require it.
> > > >
> > > > With this change, the application will be free of such constraints.
> > >
> > > [Anoob] Why don't we make it like,
> > >
> > > struct rte_event_crypto_metadata {
> > > uint64_t ev_w0_template;
> > > /**< Template of the first word of ``struct
> > > rte_event``
> > > (rte_event.event) to be set in the events generated by crypto
> > > adapter in both RTE_EVENT_CRYPTO_ADAPTER_OP_NEW and
> > >* RTE_EVENT_CRYPTO_ADAPTER_OP_FORWARD modes.
> > > */
> > > struct rte_event_crypto_request request_info; };
> > >
> > > This way, the usage would become more obvious and we will not have
> > > additional space reserved as well.
> >
> > Thanks for the suggestion. At this point, it is like an application
> > without understanding the data structure/ internals has used memcpy
> > and we are trying to fix it by changing the actual data structure
> > instead of fixing the application!
> > With this patch, the other applications(outside of dpdk) which are
> > using the data structures in a right are forced to change!
> > I don't think, this is the right way to handle this. I think, we
> > should be updating the test case and documentation for this rather
> > than changing the data structure. I expect the next version of this
> > patch should have those changes. Thanks!
>
> The point here is about making the specification better and clearer to the
> user.
> If the structure is not clear and is error prone if somebody does not follow
> Proper docume
Re: [dpdk-dev] [PATCH v1 1/5] eventdev: rx_adapter: add support to configure event buffer size
On Sat, Sep 18, 2021 at 6:41 PM Naga Harish K S V
wrote:
>
> Currently Rx event buffer is static array
> with a default size of 192(6*BATCH_SIZE).
>
> ``rte_event_eth_rx_adapter_create2`` api is added which takes
> ``struct rte_event_eth_rx_adapter_params`` to configure event
> buffer size in addition other params . The event buffer is
> allocated dynamically at run time aligned to BATCH_SIZE + 2*BATCH_SIZE.
>
> Signed-off-by: Naga Harish K S V
> Signed-off-by: Ganapati Kundapura
> ---
>
> +/**
> + * A structure to hold adapter config params
> + */
> +struct rte_event_eth_rx_adapter_params {
> + uint16_t event_buf_size;
> + /**< size of event buffer for the adapter */
See below.
> +};
> +
> /**
> *
> * Callback function invoked by the SW adapter before it continues
> @@ -330,6 +339,40 @@ int rte_event_eth_rx_adapter_create_ext(uint8_t id,
> uint8_t dev_id,
> rte_event_eth_rx_adapter_conf_cb conf_cb,
> void *conf_arg);
>
> +/**
> + * Create a new ethernet Rx event adapter with the specified identifier.
> + * This function allocates Rx adapter event buffer with the size specified
> + * in rxa_params aligned to BATCH_SIZE plus (BATCH_SIZE+BATCH_SIZE) and
> + * uses an internal configuration function that creates an event port.
This function may use for adding another
rte_event_eth_rx_adapter_params:: value.
So semantics of rte_event_eth_rx_adapter_params::event_buf_size you
can document at
in that structure. This function, you can tell it adapter creation
varint with parameters or so
See below.
> + * This default function reconfigures the event device with an
> + * additional event port and setups up the event port using the port config
> + * parameter passed into this function. In case the application needs more
> + * control in configuration of the service, it should use the
> + * rte_event_eth_rx_adapter_create_ext() version.
> + *
> + * @param id
> + * The identifier of the ethernet Rx event adapter.
> + *
> + * @param dev_id
> + * The identifier of the event device to configure.
> + *
> + * @param rxa_params
> + * Pointer to struct rte_event_eth_rx_adapter_params containing
> + * size to allocate rx event buffer.
Value NULL is allowed to represent the default values or so.
> + *
> + * @param port_config
> + * Argument of type *rte_event_port_conf* that is passed to the conf_cb
> + * function.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure
> + */
> +__rte_experimental
> +int rte_event_eth_rx_adapter_create2(uint8_t id, uint8_t dev_id,
> + struct rte_event_eth_rx_adapter_params *rxa_params,
> + struct rte_event_port_conf *port_config);
Couple of suggestion on API name and prototype:
- I think, we can remove 2 version and give more meaningful,name like
rte_event_eth_rx_adapter_create_with_param() or so
- Keep new parameter as last to have better compatibility i.e
rte_event_eth_rx_adapter_create_with_param(uint8_t id, uint8_t dev_id,
struct rte_event_port_conf *port_config, struct
rte_event_eth_rx_adapter_params *rxa_params)
Re: [dpdk-dev] [PATCH v1 3/5] eventdev:rx_adapter:add per queue event buffer configure support
On Sat, Sep 18, 2021 at 6:42 PM Naga Harish K S V
wrote:
>
> To configure per queue event buffer size, applications sets
> ``rte_event_eth_rx_adapter_params::use_queue_event_buf`` flag
> as true and is passed to `rte_event_eth_rx_adapter_create2` api.
>
> The per queue event buffer size is populated in
> ``rte_event_eth_rx_adapter_queue_conf::event_buf_size`` and passed
> to ``rte_event_eth_rx_adapter_queue_add``.
>
> Signed-off-by: Naga Harish K S V
Please change the subject to
eventdev/rx_adapter: ...
rest looks good to me.
> ---
> .../prog_guide/event_ethernet_rx_adapter.rst | 19 ---
> lib/eventdev/rte_event_eth_rx_adapter.h | 4
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> index cbf694c66b..55d09dbcb8 100644
> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> @@ -62,12 +62,14 @@ service function and needs to create an event port for
> it. The callback is
> expected to fill the ``struct rte_event_eth_rx_adapter_conf structure``
> passed to it.
>
> -If the application desires to control the event buffer size, it can use the
> -``rte_event_eth_rx_adapter_create2()`` api. The event buffer size is
> -specified using ``struct rte_event_eth_rx_adapter_params::event_buf_size``.
> -The function is passed the event device to be associated with the adapter
> -and port configuration for the adapter to setup an event port if the
> -adapter needs to use a service function.
> +If the application desires to control the event buffer size at adapter level,
> +it can use the ``rte_event_eth_rx_adapter_create2()`` api. The event buffer
> size
> +is specified using ``struct
> rte_event_eth_rx_adapter_params::event_buf_size``.
> +To configure the event buffer size at queue level, the boolean flag
> +``struct rte_event_eth_rx_adapter_params::use_queue_event_buf`` need to be
> +set to true. The function is passed the event device to be associated with
> +the adapter and port configuration for the adapter to setup an event port
> +if the adapter needs to use a service function.
>
> Adding Rx Queues to the Adapter Instance
>
> @@ -79,7 +81,9 @@ parameter. Event information for packets from this Rx queue
> is encoded in the
> ``ev`` field of ``struct rte_event_eth_rx_adapter_queue_conf``. The
> servicing_weight member of the struct rte_event_eth_rx_adapter_queue_conf
> is the relative polling frequency of the Rx queue and is applicable when the
> -adapter uses a service core function.
> +adapter uses a service core function. The applications can configure queue
> +event buffer size in ``struct
> rte_event_eth_rx_adapter_queue_conf::event_buf_size``
> +parameter.
>
> .. code-block:: c
>
> @@ -90,6 +94,7 @@ adapter uses a service core function.
> queue_config.rx_queue_flags = 0;
> queue_config.ev = ev;
> queue_config.servicing_weight = 1;
> + queue_config.event_buf_size = 1024;
>
> err = rte_event_eth_rx_adapter_queue_add(id,
> eth_dev_id,
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> b/lib/eventdev/rte_event_eth_rx_adapter.h
> index a1b5e0ed37..f9e63dc126 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> @@ -199,6 +199,8 @@ struct rte_event_eth_rx_adapter_queue_conf {
> * Valid when RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR flag is set
> in
> * @see rte_event_eth_rx_adapter_queue_conf::rx_queue_flags.
> */
> + uint16_t event_buf_size;
> + /**< event buffer size for this queue */
> };
>
> /**
> @@ -263,6 +265,8 @@ struct rte_event_eth_rx_adapter_vector_limits {
> struct rte_event_eth_rx_adapter_params {
> uint16_t event_buf_size;
> /**< size of event buffer for the adapter */
> + bool use_queue_event_buf;
> + /**< flag to indicate that event buffer is separate for each queue */
> };
>
> /**
> --
> 2.25.1
>
Re: [dpdk-dev] [PATCH v5 1/2] eventdev: add rx queue conf get api
On Thu, Sep 16, 2021 at 6:21 PM Ganapati Kundapura
wrote:
>
> Added rte_event_eth_rx_adapter_queue_conf_get() API to get rx queue
> information - event queue identifier, flags for handling received packets,
> scheduler type, event priority, polling frequency of the receive queue
> and flow identifier in rte_event_eth_rx_adapter_queue_conf structure
>
> Signed-off-by: Ganapati Kundapura
>
> ---
> v5:
> * Filled queue_conf after memzone lookup
> * PMD callback if not NULL, invoked to override queue_conf struct
> * Added memzone lookup for stats_get(), stats_reset(), service_id_get()
> api's called by secondary applications.
>
> v4:
> * squashed 1/3 and 3/3
> * reused rte_event_eth_rx_adapter_queue_conf structure in place of
> rte_event_eth_rx_adapter_queue_info
> * renamed to rte_event_eth_rx_adapter_queue_info_get() to
> rte_event_eth_rx_adapter_queue_conf_get to align with
> rte_event_eth_rx_adapter_queue_conf structure
>
> v3:
> * Split single patch into implementaion, test and document updation
> patches separately
>
> v2:
> * Fixed build issue due to missing entry in version.map
>
> v1:
> * Initial patch with implementaion, test and doc together
> ---
> ---
> .../prog_guide/event_ethernet_rx_adapter.rst | 8 ++
> lib/eventdev/eventdev_pmd.h| 28 +++
> lib/eventdev/rte_event_eth_rx_adapter.c| 91
> +-
> lib/eventdev/rte_event_eth_rx_adapter.h| 27 +++
> lib/eventdev/version.map | 1 +
> 5 files changed, 154 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> index 0780b6f..ce23d8a 100644
> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> @@ -146,6 +146,14 @@ if the callback is supported, and the counts maintained
> by the service function,
> if one exists. The service function also maintains a count of cycles for
> which
> it was not able to enqueue to the event device.
>
> +Getting Adapter queue config
> +
> +
> +The ``rte_event_eth_rx_adapter_queue_conf_get()`` function reports
> +flags for handling received packets, event queue identifier, scheduler type,
> +event priority, polling frequency of the receive queue and flow identifier
> +in struct ``rte_event_eth_rx_adapter_queue_conf``.
> +
> Interrupt Based Rx Queues
> ~~
>
> diff --git a/lib/eventdev/eventdev_pmd.h b/lib/eventdev/eventdev_pmd.h
> index 63b3bc4..e69644b 100644
> --- a/lib/eventdev/eventdev_pmd.h
> +++ b/lib/eventdev/eventdev_pmd.h
> @@ -562,6 +562,32 @@ typedef int (*eventdev_eth_rx_adapter_queue_del_t)
> int32_t rx_queue_id);
>
> /**
> + * Retrieve Rx adapter queue config information for the specified
> + * rx queue ID.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param eth_dev
> + * Ethernet device pointer
> + *
> + * @param rx_queue_id
> + * Ethernet device receive queue index.
> + *
> + * @param[out] queue_conf
> + * Pointer to rte_event_eth_rx_adapter_queue_conf structure
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure.
> + */
> +typedef int (*eventdev_eth_rx_adapter_queue_conf_get_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_eth_dev *eth_dev,
> + uint16_t rx_queue_id,
> + struct rte_event_eth_rx_adapter_queue_conf
> *queue_conf);
> +
> +/**
> * Start ethernet Rx adapter. This callback is invoked if
> * the caps returned from eventdev_eth_rx_adapter_caps_get(.., eth_port_id)
> * has RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT set and Rx queues
> @@ -1081,6 +1107,8 @@ struct rte_eventdev_ops {
> /**< Add Rx queues to ethernet Rx adapter */
> eventdev_eth_rx_adapter_queue_del_t eth_rx_adapter_queue_del;
> /**< Delete Rx queues from ethernet Rx adapter */
> + eventdev_eth_rx_adapter_queue_conf_get_t
> eth_rx_adapter_queue_conf_get;
> + /**< Get Rx adapter queue info */
> eventdev_eth_rx_adapter_start_t eth_rx_adapter_start;
> /**< Start ethernet Rx adapter */
> eventdev_eth_rx_adapter_stop_t eth_rx_adapter_stop;
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> b/lib/eventdev/rte_event_eth_rx_adapter.c
> index f2dc695..6cc4210 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -40,6 +40,8 @@
> /* Sentinel value to detect initialized file handle */
> #define INIT_FD-1
>
> +#define RXA_ADAPTER_ARRAY "rte_event_eth_rx_adapter_array"
> +
> /*
> * Used to store port and queue ID of interrupting Rx queue
> */
> @@ -1347,7 +1349,7 @@ rxa_service_func(void *args)
> static int
> rte_event_eth_rx_adapter_init(void)
> {
> - const char *name
