On 22/03/2021 10:07, Pavan Nikhilesh Bhagavatula wrote:
>
>> On 19/03/2021 20:57, pbhagavat...@marvell.com wrote:
>>> From: Pavan Nikhilesh <pbhagavat...@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 <pbhagavat...@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.
>
>>
>
