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

["Kinsella, Ray" <mdr@ashroe.eu>]

On 22/03/2021 10:07, Pavan Nikhilesh Bhagavatula wrote:
> 
>> 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.

perfect.
> 
>>
>