Re: [dpdk-dev] [EXT] Re: [PATCH v4 2/8] eventdev: introduce event vector Rx capability

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>]

>On 19/03/2021 20:57, pbhagavatula@marvell.com wrote:
>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>
>> Introduce event ethernet Rx adapter event vector capability.
>>
>> If an event eth Rx adapter has the capability of
>> RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR then a given Rx
>queue
>> can be configured to enable event vectorization by passing the
>> flag RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR to
>> rte_event_eth_rx_adapter_queue_conf::rx_queue_flags while
>configuring
>> Rx adapter through rte_event_eth_rx_adapter_queue_add.
>>
>> The max vector size, vector timeout define the vector size and
>> mempool used for allocating vector event are configured through
>> rte_event_eth_rx_adapter_queue_add. The element size of the
>element
>> in the vector pool should be equal to
>>     sizeof(struct rte_event_vector) + (vector_sz * sizeof(uintptr_t))
>>
>> Application can use `rte_event_vector_pool_create` to create the
>> vector mempool used for
>> rte_event_eth_rx_adapter_queue_conf::vector_mp.
>>
>> The Rx adapter would be responsible for vectorizing the mbufs
>> based on the flow, the vector limits configured by the application
>> and add the vector event of mbufs to the event queue set via
>> rte_event_eth_rx_adapter_queue_conf::ev::queue_id.
>> It should also mark rte_event_vector::union_valid and fill
>> rte_event_vector::port, rte_event_vector::queue.
>>
>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>> ---
>>  .../prog_guide/event_ethernet_rx_adapter.rst  | 38 ++++++++
>>  .../rte_event_eth_rx_adapter.h                | 95 +++++++++++++++++++
>>  lib/librte_eventdev/rte_eventdev.h            | 30 +++++-
>>  lib/librte_eventdev/version.map               |  2 +
>>  4 files changed, 163 insertions(+), 2 deletions(-)
>>
>
>Seems strange that you add the forward declaration of the symbol,
>and you also detail the symbol in the map file, indicating how the
>symbol should be treated.

I wanted to have only spec change here to make it easier for review,
the actual implementation is in [4/8].

>
>But the patch is missing the symbol implementation itself, it should be
>here right?
>

I will add a skeleton implementation here.

>